+ All Categories
Home > Documents > Dos and Don’ts - Iowa State Universitypublic.vrac.iastate.edu/~charding/writing/Dos and Donts...24...

Dos and Don’ts - Iowa State Universitypublic.vrac.iastate.edu/~charding/writing/Dos and Donts...24...

Date post: 13-Oct-2020
Category:
Upload: others
View: 1 times
Download: 0 times
Share this document with a friend
4
22 IEEE POTENTIALS 0278-6648/05/$20.00 © 2005 IEEE Everything has changed in publish- ing. In days of yore, there was much typing, cutting and pasting, typesetting, and proofing involved. Today, virtually everyone prepares their own typeset version of their paper. But something has been lost in the transition. There were many steps in earlier processes, but there were also many pairs of eyes involved in developing and polishing the final product. And so, over the last decade, we have seen a degradation in the quality of papers. I cannot go into much detail on the lit- erary and logical thought process that goes into writing a good paper; that is largely self- taught anyway. I will, however, attempt to correct some of the pervasive deficiencies of form and style, whose responsibility, unlike in the past, now resides with the author. These prob- lems are mostly mechanical in nature but also make it difficult for a reader to quickly assimi- late the real information. Distractions matter, and it behooves us to minimize these as much as possible so that one can concentrate on the substance in a technical paper. Fortunately, this is rather easy to reme- dy if the writer is made aware of the conventions and traditions that have evolved over many decades. I review many papers and am get- ting tired of harping on the same prob- lems and issues over and over again for every new graduate that is (or should be) struggling to produce a readable and comprehensible paper as well as seasoned authors who should know better. I am hoping to ease the burden of the reader, who as William Strunk, in The Elements of Style, said, “... was in serious trouble most of the time, a man floundering in a swamp, and that it was the duty of anyone attempting to write English to drain this swamp quickly and get this man up on the ground, or at least throw him a rope.” I am also hoping to instruct readers, so that in critically observing the writings of oth- ers they will also hopefully become better writers themselves, improving communication in the technical com- munity. I should also mention the dan- ger of being insensitive to such matters: you have to do it right the first time and always to form and retain your ability to see flaws. After touching on some general proofreading principles, I will discuss some common errors of form and style found across all forms of technical writing, including internal reports, conference papers, journal articles, and books. Remember that good habits must be scrupulously followed from the lowest to highest forms of technical publication because insensitivity will lead to inconsistency and poor quality. Proofreading and checking equations Equations used to be the bane of technical writing because the writer did not have direct control over the process. Thus, as the text was typed, retyped, and typeset, errors would inevitably creep in, and the author, having read over such equations many times, often overlooked such errors. Now the situa- tion is vastly improved, as the author prepares his own equations in typeset form from the start, and thanks to mod- ern electronic text processing, these do not change from draft to draft. But of course now the responsibility of getting equations right with the proper form and style falls squarely on the shoulders of the author; there is very little help from others to “clean up” the presenta- tion. So we have the advantage of con- sistency but also must recognize that if something is ugly it is going to stay ugly unless we fix it. It is always a good idea when proofreading your draft (at least the first time) to look at what is written on the page and check whether what you say is actually true. For example, if the text says “substituting (10) and (12) into (5) gives (15),” then take pencil and paper and make sure that this does indeed produce the stated result. Don’t rely on your previ- ous notes because you may have made a mistake in transcribing the equation to the printed page. Likewise, if you have an equation that is to be numerically evaluat- ed for values stated in the text, take out your calculator and, looking at what is printed on the page, verify that the stated numerical result is indeed obtained. All of this is a sanity check to make sure that what you are saying is actually true. You will be surprised at how many times that checking in this way will not produce the correct result! In discovering such Dennis R. Morgan ©CORBIS, ARTVILLE, RUBBERBALL of Technical Writing of Technical Writing Dos and Don’ts
Transcript
Page 1: Dos and Don’ts - Iowa State Universitypublic.vrac.iastate.edu/~charding/writing/Dos and Donts...24 IEEE POTENTIALS IEEE POTENTIALS. × ×. , = × × ()T T − [···].,,

22 IEEE POTENTIALS0278-6648/05/$20.00 © 2005 IEEE

Everything has changed in publish-ing. In days of yore, there was muchtyping, cutting and pasting, typesetting,and proofing involved. Today, virtuallyeveryone prepares their own typesetversion of their paper. Butsomething has been lost in the

transition. There were manysteps in earlier processes, butthere were also many pairs ofeyes involved in developingand polishing the final product.And so, over the last decade,we have seen a degradation inthe quality of papers. I cannotgo into much detail on the lit-erary and logical thoughtprocess that goes into writing agood paper; that is largely self-taught anyway. I will, however,attempt to correct some of thepervasive deficiencies of formand style, whose responsibility,unlike in the past, now resideswith the author. These prob-lems are mostly mechanical innature but also make it difficultfor a reader to quickly assimi-late the real information.Distractions matter, and itbehooves us to minimize these as muchas possible so that one can concentrateon the substance in a technical paper.Fortunately, this is rather easy to reme-dy if the writer is made aware of theconventions and traditions that haveevolved over many decades.

I review many papers and am get-ting tired of harping on the same prob-lems and issues over and over again forevery new graduate that is (or shouldbe) struggling to produce a readableand comprehensible paper as well asseasoned authors who should knowbetter. I am hoping to ease the burdenof the reader, who as William Strunk,in The Elements of Style, said, “... was inserious trouble most of the time, a manfloundering in a swamp, and that it wasthe duty of anyone attempting to writeEnglish to drain this swamp quicklyand get this man up on the ground, orat least throw him a rope.” I am alsohoping to instruct readers, so that incritically observing the writings of oth-ers they will also hopefully becomebetter writers themselves, improvingcommunication in the technical com-

munity. I should also mention the dan-ger of being insensitive to such matters:you have to do it right the first timeand always to form and retain yourability to see flaws.

After touching on some generalproofreading principles, I will discusssome common errors of form and stylefound across all forms of technicalwriting, including internalreports, conference papers,journal articles, and books.Remember that good habitsmust be scrupulously followedfrom the lowest to highest formsof technical publication becauseinsensitivity will lead to inconsistencyand poor quality.

Proofreading andchecking equations

Equations used to be the bane oftechnical writing because the writer didnot have direct control over the process.Thus, as the text was typed, retyped,and typeset, errors would inevitablycreep in, and the author, having readover such equations many times, oftenoverlooked such errors. Now the situa-tion is vastly improved, as the authorprepares his own equations in typesetform from the start, and thanks to mod-ern electronic text processing, these do

not change from draft to draft. But ofcourse now the responsibility of gettingequations right with the proper formand style falls squarely on the shouldersof the author; there is very little help

from others to “clean up” the presenta-tion. So we have the advantage of con-sistency but also must recognize that if

something is ugly it is going to stayugly unless we fix it.

It is always a good idea whenproofreading your draft (at leastthe first time) to look at what iswritten on the page and check

whether what you say is actuallytrue. For example, if the text says

“substituting (10) and (12) into (5) gives(15),” then take pencil and paper andmake sure that this does indeed producethe stated result. Don’t rely on your previ-ous notes because you may have made amistake in transcribing the equation tothe printed page. Likewise, if you have anequation that is to be numerically evaluat-ed for values stated in the text, take outyour calculator and, looking at what isprinted on the page, verify that the statednumerical result is indeed obtained. All ofthis is a sanity check to make sure thatwhat you are saying is actually true. Youwill be surprised at how many times thatchecking in this way will not producethe correct result! In discovering such

Dennis R.Morgan

©C

OR

BIS

, AR

TV

ILLE

, RU

BB

ER

BA

LL

of Technical Writingof Technical Writing

Dos and Don’ts

Page 2: Dos and Don’ts - Iowa State Universitypublic.vrac.iastate.edu/~charding/writing/Dos and Donts...24 IEEE POTENTIALS IEEE POTENTIALS. × ×. , = × × ()T T − [···].,,

AUGUST/SEPTEMBER 2005 23

inconsistencies, you then go back and fixthe typographical errors that have givenrise to the error. In doing so, you areguaranteeing that the reader does notwaste time trying to figure out why whatyou said doesn’t make sense.

The upside is that once you havegone through this process for a particu-lar passage of text and equations, youwill never have to do it again, thanks toelectronic text processing. (In the finalpublication process, equations some-times have to be “tuned,” so special vig-ilance is still required at this point; inthis respect, the Latex math formatter isthe most reliable and robust.)

One of the most useful features oftext processing is the ability to electroni-cally display the differences between aprevious and current version of the text.This is extremely helpful in the latestages of production when you are tiredof reading over the same thing so manytimes. If you have an ascii source file(e.g., Latex), this can be done using theUnix diff command; in Word, you canuse the “Compare Documents” feature.

General writing Author name : The author’s first

name should be spelled out, not abbre-viated with an initial, so that readersknow who you are. Author initials areonly used in citing papers, not in theoriginal paper itself!

Footnotes: Footnotes have been histori-cally used for two purposes: 1) to elabo-rate on a statement, giving further detailsand/or references, and 2) to add materialas an afterthought. The first is still war-ranted in some kinds of writing (e.g., lit-erary or medical), although not usuallyappropriate for engineering publicationsbecause it is distracting, as the reader’sgaze must shift to the footnote and thenback to the text (engineers tend to readthrough all of the details!). In manycases, the details can be put right into thetext, in parentheses, or if too long, in anappendix. The second purpose of foot-notes, to add material as an afterthought,was historically used as a pragmaticexpediency, as printed text was difficultto change. With modern text processing,this usage is totally obsolete because onecan easily insert or delete text at will.

Quotation marks: In ordinary writ-ing, use double quotes to quibble withthe meaning of a word or give allegori-cal meaning. (Single quotes are for c-code and MATLAB and should beavoided in ordinary writing.) For exam-ple, one would say:

The “optimal” value of x here israther elusive because there arecompeting objectives.

Note that any punctuation at the end ofa quoted phrase is placed before theclosing quotation mark, e.g.,

When he said “stop,” he did notreally mean it.

Do not use double quotes for definingwords (see Italics below).

Capitalization: Don’t capitalizegeneric phrases such as code-divisionmultiple access (CDMA) or bit error rate(BER). Do capitalize phrases that areproper names such as Universal MobileTelecommunications System (UMTS) andalso words in phrases that are propernames like fast Fourier transform (FFT).Capitalize words referring to specificparts of the text, e.g., Section A, Figure3, Table II, and Appendix C, as well asspecific enumerated entities like User A,Receiver 1, and Algorithm I.

Italics: For emphasis of words, useitalic font. Don’t use underline; thatconvention is a carryover from old-fash-ioned typewriters, which didn’t havefont selection. Italic is also used todefine new or unfamiliar terms, but notfor terms that are (presumably) wellknown to most readers. Thus, use italicsthe first (and only first) time the newterm is encountered, e.g., “We shallrefer to this quantity as backoff, mea-sured in decibels. For the above exam-ple, the backoff was set to –10 dB rela-tive to the peak power.”

Spacing: Always use a space betweena number and its unit, e.g., 5 dB.However, if the quantity is used as anadjective, the number and its unit arehyphenated, e.g., 5-dB contours.

Hyphens and dashes: Use hyphens forcompound adjectives, e.g., time-domainanalysis. Note that a hyphen is not nec-essary with th, as in nth, or in othersuch constructions. Also note that ahyphen (-) is not a substitute for thedash. There are two kinds of dashes: along (em) dash (—), which is used toset off a subordinate clause, and, ashort (en) dash (–), which is used toexpress to, or through, as in a range ofnumbers, e.g., pp. 6–9.

Numerals: For numerals, use thewords “one, two, ... , nine” for enumer-ating objects and “1, 2, ... , 9” fornumerical values. Thus, e.g., write “Weuse two antennas in this configuration,”but “We assume that x is greater than1.” For 10 and above, common publish-er style uses numerals, e.g., “We use 25antennas in this configuration.” You’ll

always want to follow the style of thepublication for which you are writing.

Page numbers: Always number pagesso that reviewers can refer to specificsin the text. This also aids in the finalproduction, whereby the author cancommunicate with the publisher by ref-erence to the original manuscript.

Word usage Here we just mention some of the

more common errors found in engi-neering journals. More general wordusage rules can be found in TheElements of Style.

That and which: Use that in a defin-ing relative clause and which for non-defining relative clauses:

The filter that has just been provedpermits us . . . This theorem, which was proved byBrown, permits us . . .

A simple test for defining clauses is toask yourself the question “which one?”and if you can answer meaningfully,then use “that.” For example, in theabove, you ask “which filter?” and theanswer is “the one that has just beenproved,” so use “that.”

Can and may: Distinguish can andmay:

According to (15), this expressioncan be written as . . . Interested readers may requestcopies of the report . . . Affect and effect: Distinguish between

affect (to cause something to change)and effect (the result of some change).

Notice and note: Note that you noticesomeone walking down the street, butyou note something that requires mentaldeduction, not merely observation.Thus, e.g., one says “Notice in Fig. 1that the curves all converge as xincreases,” but “Note that in the aboveequation, the limiting value of f (x) asx → ∞ is π/2.’’

Notation, distortion, performance: Inthe context of defining mathematicalsymbols, the word notation is a collec-tive noun and does not use an “s” onthe end. Thus, one says, e.g., “Thenotation used in this paper is summa-rized in Table I.” In ordinary usage, theplural form “notations” is sometimesused, as in, e.g., “Examination ofNewton’s original text shows severalnotations in the margins dealing withspecial cases.” The words “distortion”and “performance” are almost alwaysused in the singular collective sense.

e.g. and i.e.: When using the expres-sions e.g. (“for example”) and i.e. (“that

Page 3: Dos and Don’ts - Iowa State Universitypublic.vrac.iastate.edu/~charding/writing/Dos and Donts...24 IEEE POTENTIALS IEEE POTENTIALS. × ×. , = × × ()T T − [···].,,

24 IEEE POTENTIALS

is”), note that a comma should alwaysbe used before and after the expression,except when used to start a parentheti-cal comment, in which case the initialcomma is omitted. (An exception for thecase when these are used at the begin-ning of a sentence is not necessarybecause such usage is to be avoided.)

Jargon: Avoid technical jargon thatcombines words to make up new wordsthat are not in the dictionary (e.g.,pathloss, basestation, etc.). A good wayto test for current accepted usage is tosearch journal article titles in an elec-tronic database, such as IEEE Xplore.(Limiting the search to titles in journalarticles obtains the most reliable resultssince many people in the production ofa paper at least look at the title.)

Conclusions: The final section of apaper should be titled “Conclusions”not “Conclusion;” you are not conclud-ing the paper, you are giving your con-clusions of the study, which is a differ-ent usage of the word.

Mathematics Starting sentences: Don’t start a sen-

tence with a math symbol. It slowsdown the reader because the beginningof a sentence is signaled by an initialcapitalized ordinary word. So when amath symbol is the subject of a sen-tence, preface it with something like“Here, ...” or “In this case, ...”.

Font style: Use italic font for all ordi-nary (single-character) math variables,e.g., x, y. Although it is never a good ideato use more than one character for amath variable, if you insist on usingsomething like SNR (signal-to-noise ratio),use a roman font because math italic SNRwill not be spaced properly and more-over can be misinterpreted as the productof three variables, S × N × R .

Font size: Use one consistent fontsize throughout for the principal part ofall math symbols, with consistentreduced font size for subscripts andsuperscripts. (Latex does all of thesethings, and more, automatically.)

Bold fonts: Authors should considerusing a bold font for vectors (lowercase) and matrices (upper case)because, unlike in the past, we haveready access to this option, and mosttechnical writers of journal articles andbooks currently adopt this convention.Again, it helps readers if a common lan-guage is established so they can con-centrate on the substance of the paperwithout the distraction of having to fig-ure out what is meant by strange and

unfamiliar notation. Furthermore,although scalar math variables are tradi-tionally italicized, it is preferable to usebold roman instead of bold italic forvectors and matrices; it is less confusing,and most books and journals, theAmerican Institute of Physics, and manyother publishers now use bold roman.

Abbreviations: Ordinary words orabbreviations of words in mathematicalsymbols, particularly subscripts, shouldbe in roman, not italic, font, so that theyare not misinterpreted as math symbolsthemselves. For example, write xi (italici) for the ith component of a vector xbecause i is a math variable, but write xi(roman i) to denote a variable x mea-sured at the input (i here is an abbrevia-tion of “input” and is not a math vari-able). Likewise, write ymin , yopt , etc.Also, when units like “dB” are includedin mathematical expressions, specialcare must be taken to render them inroman, not italic, font (“d” and “B” arenot math variables here!)

Functions and operators: Note thatmath functions of more than one charac-ter like sin( ), cos( ), exp( ), log( ), andmax( ) should be roman font, not italic,to distinguish them from a product ofordinary math variables (e.g.,s in = s × i × n). Although a contraven-ing argument can be made, operatorslike expectation E and the transposesuperscript ( )T are by and large ren-dered in italic font, which is perhaps forthe better to avoid possible confusionwith (roman) abbreviations of words.

Superscripts: If x(n) is a vectorsequence, write xT (n), not x(n)T for thetranspose. Likewise, for a scalarsequence x(n), the square is writtenx2(n), not x(n)2. Note that superscriptsand subscripts should be horizontallyaligned, one directly above the other,e.g., write x2

n , not xn2. In general, avoid

numerical superscript indexes, whichcan be confused with ordinary expo-nents. If you must use such indexes,write, e.g., x(2)

n to denote the index, notx2n , which looks like the square of xn

Minus signs: Use a minus sign (–)not a hyphen (-) in math expressions,e.g., x − y. Displayed equations withmath formatters like Latex automatical-ly do this, but particular attention mustbe paid to inline text. (It is good prac-tice to always use the math formatmode to enter in-text math.) Also, usethe minus sign for inline numericalquantities, e.g., –10 dB. Also take careto follow these rules for figures, espe-cially block diagrams.

Spacing: Use a space before andafter +, −, =, e.g., 1 + 2 = 3. Also, useproper spacing for arrays, viz.,[ x1 x2 · · · xN ].

Fractions: Don’t let the point sizereduce for fractions in displayed equa-tions. In Latex, the font size of fractionsin displayed equations will occasionallyreduce in font size, which is undesir-able. To remedy this use \dfrac:

\newcommand{\dfrac}[2]{\frac{\dis-playstyle#1}{\displaystyle#2}}.

Inline math fractions that appear in thetext should be written as x/y rather than x

yto maintain consistent font size and avoidinconsistent spacing between lines of text.

Nested parentheses: Nested parenthe-ses (()) should be avoided, preferringthe standard hierarchy {[()]} instead.MATLAB doesn’t have trouble inter-preting nested parentheses, buthumans do. The eye wants to parse amathematical expression to distinguishthe various orders of suboperations.That is why the standard mathematicalhierarchy is traditionally used: to helpthe reader assimilate the meaning ofthe expression.

Punctuation: Equations, like text,should be properly punctuated so thatthe reader knows when to stop, when topause, and when to read on. Therefore,if an equation is at the end of a sen-tence, put a period at the end. If thesentence continues on after the equationand grammatically calls for a pause, youcan optionally put a comma at the endof the equation, although some writersconsider this unnecessary because theinterjection of a displayed equation(without a comma at the end) automati-cally suggests a pause (some IEEE trans-actions adopt this point of view).

Definitions: Always define new termsand variables where they are first intro-duced and not several sentences, para-graphs, or even pages later. There isnothing more frustrating to a reader thanthe introduction of undefined terms.Also, don’t bury important definitions inthe text; make them stand-alone, dis-played equations so that a reader canquickly find and refer back to them.

Numbering: In most cases, don’tnumber a collection of N quantities asn = 0, 1, . . . , N − 1 , since it is quiteunnatural to count items starting withzero. Therefore, a collection of N quan-tities should usually be designated asn = 1, 2, . . . , N . The exception is fordigital number representations, DFT/FFTconstructions, and the like, where start-ing with zero makes sense.

Page 4: Dos and Don’ts - Iowa State Universitypublic.vrac.iastate.edu/~charding/writing/Dos and Donts...24 IEEE POTENTIALS IEEE POTENTIALS. × ×. , = × × ()T T − [···].,,

AUGUST/SEPTEMBER 2005 25

Some common errors ofIEEE Transactions authors

Section numbers: In IEEE journals andtransactions, use IEEE-style sectionnumbering,., I, II, ... , etc. for major sec-tion headings, A, B, ... , etc. for subsec-tions, and 1, 2, ... , etc. for subsubsec-tions. Much of this is done automatical-ly when using IEEE templates.

Figures: The word “Figure(s)” isabbreviated as “Fig(s).” Put the entirecaption below the figure. If there aresubplots, label them as (a), (b), etc.,and put the description of these in themain caption. Don’t use the same cap-tion for two different figures. Avoid rep-etition, but include as much detail asnecessary to distinguish figures. In gen-eral, keep figure captions short, relyingon the text to give context, relevance,and verbose detail.

References: Standard IEEE citationof references is [1], [2] and [3]–[5], not[1,2] and [3–5], respectively. If a cer-tain page number or chapter is beingcited, write as, e.g., [1, p. 7] or [2, ch.3]. IEEE style requires references to belisted numerically in the order of theircitation, [1], [2], etc.. Most other jour-nals also follow this practice, whichhas several advantages. First, the read-er can follow the citations much easierif they are cited in order because onethen doesn’t have to go jumpingthrough the reference listing in ran-dom order. Second, if one sees a par-ticular familiar work in the referencelisting, it can be easily located in thetext to see how it is specifically rele-vant to the present work. Finally, itserves as a check to make sure youhave cited all of the references in thelist, which is difficult to do if not citedin order. The alternative is to alpha-betically order the reference listingwith respect to the principle author’slast name. Although a few journalshave adopted this practice (e.g.,Elsevier Signal Processing and somepast ICASSP proceedings), the practiceis arguably inferior, the only exceptionbeing possibly for a survey-type articleor textbook that has a large number ofreferences, say, 100 or more.

Use correct IEEE reference style(see IEEE’s Information for Authors orany IEEE journal). For multipleauthors, use the form “Author1 andAuthor2” or “Author1, Author2, andAuthor3” (note the final comma andthe word “and”). Only capitalize thefirst word of article titles for journalsand conference papers, using double

quotes before the first word and fol-lowing a comma after the last word.For journal articles, properly abbrevi-ate the journal title, use “vol.” and“no.” (no capitals), give page numbersas “pp.,” and abbreviate the month,e.g., Jan., Feb. For conference pro-ceedings, put “in Proc.” before the con-ference title and include page numbersafter the year (like for a book).

Conclusions All of the forgoing discussion is

predicated on the current state of theart in electronic text processing. In thefuture, some of the details may requiremodification or be rendered obsolete asthe technology progresses. Neverthe-less, the basic principles and goal willremain unchanged, that of producingliterate, consistent, and readily compre-hensible technical writing.

Acknowledgments Thanks are expressed to D. Melley

and staff at IEEE Editorial Services, S.J.Elliott, S. Haykin, and T. Gaensler forcarefully reading a draft of this work

and providing useful suggestions forimprovement as well as generalencouragement.

Read more about it • W. Strunk, Jr. and E.B. White, The

Elements of Style. New York: Macmillan,1972.

• The Chicago Manual of Style .Chicago: Univ. of Chicago Press, 1993.

• M. Skillen, Words into Type.Englewood Cliffs, NJ: Prentice-Hall, 1974.

• “Advice to authors,” IEEE Trans.Inform. Theory, vol. IT-15, p. 338, Mar.1969.

• “Advice to authors,” IEEE Trans.Inform. Theory, vol. IT-30, p. 453, Mar.1980.

• Information for authors, IEEEPeriodicals, [Online]. Available: http://www.ieee.org/organizations, click onPublications, Author & SubmissionGuidelines, IEEE Transactions andJournals, Information for Authors.

About the authorDennis Morgan is with Bell

Laboratories, Lucent Technologies.

Erik Jonsson School of Engineering & Computer ScienceThe University of Texas at Dallas

The Jonsson School of Engineering and Computer Science isseeking exemplary graduate scholars for several JonssonSchool Distinguished Research Assistantships. The ECSDepartment grants graduate degrees in Computer Science,Software Engineering, Electrical Engineering, ComputerEngineering and Telecommunications Engineering. Newemerging programs in Materials Science and BioEngineeringare in process. The Distinguished Research Assistantships’monthly stipend ranges from $1800 - $2200, and tuition andfees are also waived. The assistantship is renewable yearly.

Within the UTD Engineering and Computer ScienceDepartment, major research areas include Materials Scienceand Nanotechnology, Digital and Analog Systems, SignalProcessing, Communications, Microelectronics and Optics,Intelligent Systems, Computer Systems, Software Engineering,Networking, Algorithms and Applications, ComputerEngineering, Cybersecurity and Information Assurance, andTelecommunications Engineering.

Because of UTD’s location in the 2nd

largest high-tech region inthe US, we are able to work closely with industry to understandcurrent and future research needs, and to provide UTDgraduates to meet their employment needs.

Questions? [email protected]. To apply, visit:

http://utdallas.edu/student/admissions/prospective/

The University of Texas at Dallas is an equal opportunity/affirmativeaction university.


Recommended