how to write a technical report in computer science

University Libraries      University of Nevada, Reno

• Skill Guides
• Subject Guides

Computer Science: Technical Reports & Standards

• Articles, eBooks, & Databases
• Technical Reports & Standards
• Software & Programming Languages
• Systematic Reviews

What is a Technical Report?

Technical reports describe the process, progress, or results of technical or scientific research. They include in-depth experimental details, data, and results.

Reasons to Use

Technical reports are usually produced to report on a specific research need. They can serve as a report of accountability to the organization funding the research. They provide access to the information before it is published elsewhere.

How to Write a Technical Report

Here are some resources that help explain what is usually included in a technical report and how to write them!

• Technical Report Tutorial from CSU
• Guide to Technical Report Writing from the University of Sussex

Search for Full-Text Standards at UNR

• ASTM Compass has created six types of standards that relate to manufacturing processes such as testing, materials classification and operation. The six types are test method, specification, classification, practice, guide and terminology standards.
• IEEE Xplore/IET Electronic Library (IEL) Includes full-text access to IEEE transactions, journals, magazines and conference proceedings published since 1988 and all current IEEE Standards.
• SAE Mobilus Produced by SAE International, this resource indexes e-books, technical papers, standards, and conference proceedings relating to mobility systems engineering in the aerospace, automotive, and commercial vehicle industries. Note: Please see the SAE Mobilus LibGuide for information on setting up your access.
• ASSIST Quick Search - Military Standards Full text of most military and federal standards.
• Everyspec Full text of military and government standards.
• International Telecommunication Union (ITU-T) Full text of International Telecommunication Union's standards and recommendations.
• Look in Library Search for Print ISO Standards You can search the catalog for individual ISO standards that the library has purchased here.

Technical Report Resources

• National Technical Reports Library (NTRL) The National Technical Reports Library provides access to US Federal government technical reports in science and technology. It indexes about 2,000,000 reports and currently provides access to PDF copies of some 800,000 reports published since 1995. (More reports will be added, as pre-1995 reports are scanned.) Note that while access is free to the public, you must register with NTRL to gain access, and you may only download five reports per session. Also, free access is only available within the borders of the United States of America.
• DTIC Online: Public Technical Reports Citations to unclassified unlimited documents entered into the Defense Technical Information Center's Technical Reports Collection from 1974 to present. Also offers full text documents September 1998 to present. DTIC has many full text documents available. If full text is not available for a desired report, contact a librarian at DeLaMare Library. We would be happy to request a digitized copy for you.
• NEPIS (National Environmental Publications Information System) Provides full text access from a collection of over 7,000 archival and current documents published by the Environmental Protection Agency. Allows searching, viewing, and printing, including full images of all original pages and full-text. Includes documents that are no longer available in print form.

What is a Standard?

Standards and their development frame, guide, and normalize almost all areas of our lives.  For example, standards in IT govern interoperability between a variety of digital devices and platforms, standardized production of various machine parts allows uniform repair and reproduction. Standardization in fields like accounting, health care, or agriculture promotes best industry practices that emphasize safety and quality control.

Standards reflect the shared values, aspirations, and responsibilities we as a society project upon each other and our world.   Keeping informed about the most current standards can drive innovation and increase the market value of an engineer’s research and design efforts as well as promoting international trade and commerce, which then fuels more innovation.

• Watch: International Standards Organization's  What Standards Do For You
• This course is designed as a basic introduction to standards for management and technical personnel in business, industry association management, government, and public policy; university faculty and students; engineers, quality control and purchasing staff; consumers; and those new to organizations that develop standards.

Types of Standards: 

• Examples: ISO film speed code; banking and telephone cards
• Examples: Safety of wire ropes; safety of toys
• Examples: ISO 9000 Quality and Environmental Management Systems
• Examples: Financial planners  

Reasons to Use Standards

Standards allow technology to work seamlessly and establish trust so that markets can operate smoothly. They:

• provide a common language to measure and evaluate performance
• make interoperability of components made by different companies possible
• protect consumers by ensuring safety, durability, and market equity

(From  NIST )

• << Previous: Articles, eBooks, & Databases
• Next: Software & Programming Languages >>

The Components

Organization, special notes on experimental work, delivery forms, common mistakes to avoid, additional advice, other important communication forms.

• Accessibility
• Staff search
• External website
• Schools & services
• Sussex Direct
• Professional services
• Schools and services
• Engineering and Informatics
• Student handbook
• Engineering and Design
• Study guides

Guide to Technical Report Writing

• Back to previous menu
• Guide to Laboratory Writing

School of Engineering and Informatics (for staff and students)

Table of contents

1 Introduction

2 structure, 3 presentation, 4 planning the report, 5 writing the first draft, 6 revising the first draft, 7 diagrams, graphs, tables and mathematics, 8 the report layout, 10 references to diagrams, graphs, tables and equations, 11 originality and plagiarism, 12 finalising the report and proofreading, 13 the summary, 14 proofreading, 15 word processing / desktop publishing, 16 recommended reading.

A technical report is a formal report designed to convey technical information in a clear and easily accessible format. It is divided into sections which allow different readers to access different levels of information. This guide explains the commonly accepted format for a technical report; explains the purposes of the individual sections; and gives hints on how to go about drafting and refining a report in order to produce an accurate, professional document.

A technical report should contain the following sections;

For technical reports required as part of an assessment, the following presentation guidelines are recommended;

There are some excellent textbooks contain advice about the writing process and how to begin (see Section 16 ). Here is a checklist of the main stages;

• Collect your information. Sources include laboratory handouts and lecture notes, the University Library, the reference books and journals in the Department office. Keep an accurate record of all the published references which you intend to use in your report, by noting down the following information; Journal article: author(s) title of article name of journal (italic or underlined) year of publication volume number (bold) issue number, if provided (in brackets) page numbers Book: author(s) title of book (italic or underlined) edition, if appropriate publisher year of publication N.B. the listing of recommended textbooks in section 2 contains all this information in the correct format.
• Creative phase of planning. Write down topics and ideas from your researched material in random order. Next arrange them into logical groups. Keep note of topics that do not fit into groups in case they come in useful later. Put the groups into a logical sequence which covers the topic of your report.
• Structuring the report. Using your logical sequence of grouped ideas, write out a rough outline of the report with headings and subheadings.

N.B. the listing of recommended textbooks in Section 16 contains all this information in the correct format.

Who is going to read the report? For coursework assignments, the readers might be fellow students and/or faculty markers. In professional contexts, the readers might be managers, clients, project team members. The answer will affect the content and technical level, and is a major consideration in the level of detail required in the introduction.

Begin writing with the main text, not the introduction. Follow your outline in terms of headings and subheadings. Let the ideas flow; do not worry at this stage about style, spelling or word processing. If you get stuck, go back to your outline plan and make more detailed preparatory notes to get the writing flowing again.

Make rough sketches of diagrams or graphs. Keep a numbered list of references as they are included in your writing and put any quoted material inside quotation marks (see Section 11 ).

Write the Conclusion next, followed by the Introduction. Do not write the Summary at this stage.

This is the stage at which your report will start to take shape as a professional, technical document. In revising what you have drafted you must bear in mind the following, important principle;

• the essence of a successful technical report lies in how accurately and concisely it conveys the intended information to the intended readership.

During year 1, term 1 you will be learning how to write formal English for technical communication. This includes examples of the most common pitfalls in the use of English and how to avoid them. Use what you learn and the recommended books to guide you. Most importantly, when you read through what you have written, you must ask yourself these questions;

• Does that sentence/paragraph/section say what I want and mean it to say? If not, write it in a different way.
• Are there any words/sentences/paragraphs which could be removed without affecting the information which I am trying to convey? If so, remove them.

It is often the case that technical information is most concisely and clearly conveyed by means other than words. Imagine how you would describe an electrical circuit layout using words rather than a circuit diagram. Here are some simple guidelines;

The appearance of a report is no less important than its content. An attractive, clearly organised report stands a better chance of being read. Use a standard, 12pt, font, such as Times New Roman, for the main text. Use different font sizes, bold, italic and underline where appropriate but not to excess. Too many changes of type style can look very fussy.

Use heading and sub-headings to break up the text and to guide the reader. They should be based on the logical sequence which you identified at the planning stage but with enough sub-headings to break up the material into manageable chunks. The use of numbering and type size and style can clarify the structure as follows;

• In the main text you must always refer to any diagram, graph or table which you use.
• Label diagrams and graphs as follows; Figure 1.2 Graph of energy output as a function of wave height. In this example, the second diagram in section 1 would be referred to by "...see figure 1.2..."
• Label tables in a similar fashion; Table 3.1 Performance specifications of a range of commercially available GaAsFET devices In this example, the first table in section 3 might be referred to by "...with reference to the performance specifications provided in Table 3.1..."
• Number equations as follows; F(dB) = 10*log 10 (F) (3.6) In this example, the sixth equation in section 3 might be referred to by "...noise figure in decibels as given by eqn (3.6)..."

Whenever you make use of other people's facts or ideas, you must indicate this in the text with a number which refers to an item in the list of references. Any phrases, sentences or paragraphs which are copied unaltered must be enclosed in quotation marks and referenced by a number. Material which is not reproduced unaltered should not be in quotation marks but must still be referenced. It is not sufficient to list the sources of information at the end of the report; you must indicate the sources of information individually within the report using the reference numbering system.

Information that is not referenced is assumed to be either common knowledge or your own work or ideas; if it is not, then it is assumed to be plagiarised i.e. you have knowingly copied someone else's words, facts or ideas without reference, passing them off as your own. This is a serious offence . If the person copied from is a fellow student, then this offence is known as collusion and is equally serious. Examination boards can, and do, impose penalties for these offences ranging from loss of marks to disqualification from the award of a degree

This warning applies equally to information obtained from the Internet. It is very easy for markers to identify words and images that have been copied directly from web sites. If you do this without acknowledging the source of your information and putting the words in quotation marks then your report will be sent to the Investigating Officer and you may be called before a disciplinary panel.

Your report should now be nearly complete with an introduction, main text in sections, conclusions, properly formatted references and bibliography and any appendices. Now you must add the page numbers, contents and title pages and write the summary.

The summary, with the title, should indicate the scope of the report and give the main results and conclusions. It must be intelligible without the rest of the report. Many people may read, and refer to, a report summary but only a few may read the full report, as often happens in a professional organisation.

• Purpose - a short version of the report and a guide to the report.
• Length - short, typically not more than 100-300 words
• Content - provide information, not just a description of the report.

This refers to the checking of every aspect of a piece of written work from the content to the layout and is an absolutely necessary part of the writing process. You should acquire the habit of never sending or submitting any piece of written work, from email to course work, without at least one and preferably several processes of proofreading. In addition, it is not possible for you, as the author of a long piece of writing, to proofread accurately yourself; you are too familiar with what you have written and will not spot all the mistakes.

When you have finished your report, and before you staple it, you must check it very carefully yourself. You should then give it to someone else, e.g. one of your fellow students, to read carefully and check for any errors in content, style, structure and layout. You should record the name of this person in your acknowledgements.

Two useful tips;

• Do not bother with style and formatting of a document until the penultimate or final draft.
• Do not try to get graphics finalised until the text content is complete.
• Davies J.W. Communication Skills - A Guide for Engineering and Applied Science Students (2nd ed., Prentice Hall, 2001)
• van Emden J. Effective communication for Science and Technology (Palgrave 2001)
• van Emden J. A Handbook of Writing for Engineers 2nd ed. (Macmillan 1998)
• van Emden J. and Easteal J. Technical Writing and Speaking, an Introduction (McGraw-Hill 1996)
• Pfeiffer W.S. Pocket Guide to Technical Writing (Prentice Hall 1998)
• Eisenberg A. Effective Technical Communication (McGraw-Hill 1992)

Updated and revised by the Department of Engineering & Design, November 2022

School Office: School of Engineering and Informatics, University of Sussex, Chichester 1 Room 002, Falmer, Brighton, BN1 9QJ [email protected] T 01273 (67) 8195 School Office opening hours: School Office open Monday – Friday 09:00-15:00, phone lines open Monday-Friday 09:00-17:00 School Office location [PDF 1.74MB]

Copyright © 2023, University of Sussex

• Academic Skills
• Report writing

Technical report writing

A quick guide to writing technical reports in Engineering.

The main purpose of an Engineering technical report is to present a solution to a problem in order to prompt action. Technical reports provide a record of your developing expertise and are a legal record of your work and decision making.

What is a technical report?

Technical reports are a central part of your professional success and are usually designed to:

• Convince the reader of your position
• Persuade them to act, or
• Inform them of your findings.

They are an opportunity for you to:

• Clearly communicate a solution to a problem
• Recommend action, and
• Aid decision making.

Technical reports are designed for quick and easy communication of information, and use:

• Sections with numbered headings and subheadings, and
• Figures and diagrams to convey data.

How do I structure a technical report?

Regardless of the specific purpose of your technical report, the structure and conventions rarely differ. Check your subject requirements and expand the sections below to learn more about each section. Download a Technical Report template here.

Technical reports usually require a title page. To know what to include, follow the conventions required in your subject.

A technical report summary (or abstract) should include a brief overview of your investigation, outcomes and recommendations. It must include all the key information your reader needs to make a decision, without them having to read your full report. Don’t treat your summary as an introduction; it should act as a stand-alone document.

Tip: Write your summary last.

Help your reader quickly and easily find what they are looking for by using informative headings and careful numbering of your sections and sub-sections. For example:

A technical report introduction:

• provides context for the problem being addressed,
• discusses relevant previous research, and
• states your aim or hypothesis.

To help, consider these questions:

• What have you investigated?
• How does your study fit into the current literature?
• What have previous studies found in the area?
• Why is it worth investigating?
• What was the experiment about?
• Why did you do it?
• What did you expect to learn from it?

The body of a technical report is structured according to the needs of your reader and the nature of the project. The writer decides how to structure it and what to include.

To help, ask yourself:

• What does the reader need to know first?
• What is the most logical way to develop the story of the project?

Tip: look at other technical reports in your discipline to see what they’ve included and in what order.

Technical reports include a mixture of text, tables, figures and formulae. Consider how you can present the information best for your reader. Would a table or figure help to convey your ideas more effectively than a paragraph describing the same data?

Figures and tables should:

• Be numbered
• Be referred to in-text, e.g. In Table 1 …, and
• Include a simple descriptive label - above a table and below a figure.

Equations and formulae should be:

• Referred to in-text, e.g. See Eq 1 for …
• Centred on the page, and
• On a separate line.

Your conclusion should mirror your introduction.

Be sure to:

• Refer to your aims
• Summarise your key findings, and
• State your major outcomes and highlight their significance.

If your technical report includes recommendations for action. You could choose to report these as a bullet point list. When giving an answer to your problem, be sure to include any limitations to your findings.

Your recommendations can be presented in two ways:

• Action statements e.g. Type approval should be issued for tunnel ventilation fans.
• Conditional statements e.g. If fan blades are painted with an anti-corrosion coating system, it is likely that… e.g. The research has found that the fan hub should be constructed from forged steel and the fan housing should be constructed from hot dipped galvanised steel, but future research…

Acknowledge all the information and ideas you’ve incorporated from other sources into your paper using a consistent referencing style. This includes data, tables and figures. Learn more about specific referencing conventions here: https://library.unimelb.edu.au/recite

If you have data that is too detailed or lengthy to include in the report itself, include it in the appendix. Your reader can then choose to refer to it if they are interested. Label your appendix with a number or a letter, a title, and refer to it the text, e.g. For a full list of construction phases, see Appendix A.

Looking for one-on-one advice?

Get tailored advice from an Academic Skills adviser by booking an individual appointment, or get quick advice from one of our Academic Writing Tutors in our online drop-in sessions.

Get one-on-one advice

Computer Science

Technical reports.

The links on this page are to technical/research reports for each year listed up to 2000. They are listed by tr number in chronological order. The number of reports for each month/year varies.

Reports with electronic versions have a link to the paper in .tex, .pdf and/or .ps format listed next to the report number in brackets.  

Reports older than 2000 can be found here .

Technical Report Guidelines and Suggestions

As course assignments, technical reports serve a few purposes. Often, they provide a way to communicate some work you have done to the course instructor, whether completing a lab, performing an analysis, developing some software, etc. This allows for assessment and for helpful feedback if needed. Always, though, they are practice for technical writing skills that will be important in any work you do after graduation. Saying, “Yeah, I did it; here it is,” is rarely sufficient; your manager, client, advisor, coworkers, or colleagues need context, background, process, pitfalls, results, and all the rest to really know what you did and accept it. The organization, flow, writing mechanics, and clarity are also important aspects of this communication.

All of the following is important, so please do pay attention and let me know if anything is unclear. I do not want to have to copy any of the below points verbatim into report feedback…

The following applies to technical reports in general. Certain classes have additional specific guidelines:

• CS256 - Computer Organization and Architecture - Lab reports
• CS354 - Algorithm Design and Analysis - Empirical analysis reports

Writing is communication, and communication is only effective when it conveys the intended information or has the intended effect on the audience of that communication. Keeping the audience in mind is critical, then, for writing effectively. Different audiences need different things for writing to be effective.

In “real” technical writing, you will usually have an audience in mind and know something about their background and what the goal of the report is for them, and that should guide the choices you make in your writing.

In writing for a class, you often must assume a particular audience and practice writing for that imagined group of people. For most class reports, unless specified otherwise, assume the audience of your report is students like you , with a background similar to what you had before you began the work you’re writing about. The goal of your report should be to explain your work and your results in sufficient detail for someone with that background to A) understand, and B) be able to reproduce your work.

Report Format ¶

Reports should be a professional document describing your work in enough detail that it could be replicated by another with your background, including all designs, experiments, and data gathered. Technical reports generally use something like the following organization:

Title: Title, course, your name, any partners’ names (if relevant), date(s) worked (if relevant), and date submitted.

Introduction: Describe the goal(s) of the work, and include any relevant context or background information (e.g., from the lectures or the reading). It is often useful to provide a brief summary of your results and outcomes here as well.

Experiment/Methodology: Describe what you did . The details here will depend on the type of work you are doing. Specific suggestions for reports in particular classes are linked below.

Results/Analysis/Discussion: Discuss the outcomes of your work. If you gathered data, present and analyze it here. If you were trying to answer some question(s) or test some hypothesis, provide the answers and/or results here, supported by any data gathered during your work. If an assignment posed explicit questions for you to answer, this is often a good place to do so (though some answers may fit more naturally in an earlier section).

Summary: Summarize the process and outcomes of the work as they relate to the objectives. What did you learn? What conclusions can you draw from what you did and observed? What further work or exploration could this lead to?

Not all reports have to follow this outline exactly, of course, but it provides a good starting point. Often with labs that have multiple independent parts, for example, it may make more sense to break the report into parts, where each part contains its own methodology and results/analysis. This works well if there are many different steps for which it makes more sense to keep the separate results close to the methodology that produced them.

Keep the audience in mind while writing, and consider it from their perspective: what organization will be most understandable and flow well?

Guidelines ¶

Many of the following are quoted or adapted from these guidelines for writing lab reports in a class at the University of Pennsylvania.

Keep your reader in mind always. The reader should understand your report (purpose of the work, process and results, and conclusions) in one reading without having to go back and forth within your paper, and without access to the list of questions you were given.

Keep your report as succinct as possible without leaving out necessary detail. Every word should count.

Technical writing needs to be very careful with technical terms and concepts. Words often have very precise meanings, and it is important to use them correctly. Further, the audience will often not be familiar with all of the terms you use, in which case those terms should be defined clearly when first used.

Try to step back from the list of questions you were given for an assignment, if any. Answering a list of questions does not prepare you for professional technical writing. The answers should be in your report, but an organized and coherent report will not read like a list of answers.

Talk about other interesting things you stumbled across in the course of your work which were not included in your aims. However, use careful wording and organization to make sure that the reader can keep sight of the main point of your conclusion, which is to relate your results to your initial aims.

The writing should usually be a narrative . Don’t just provide bullet points of technical details, answers to questions, and raw data. Describe and explain what you did to give context to the details, answers, and data.

Organization ¶

With any writing, organization is important for maintaining a logical flow of ideas throughout. In technical writing, this can be even more important, as the writing may be read as a single, complete piece or by referencing one or more specific sections from the whole.

Using explicit headings can clearly denote major sections of the writing.

Write a clear introduction and conclusion to provide context up front and to summarize at the end.

Think about how to organize your points to group them and avoid tedious repetition of equivalent or similar details.

Formatting & Presentation ¶

Consider numbering the sections of the report. Doing so will make it easier for you to refer to another section or subsection if you need to.

Label and caption figures and tables. Figures, for example, should be called “Figure 1”, “Figure 2”, etc. (or include the section number, such as “Figure 1.3” for the third figure in section 1) with a brief descriptive caption for each. Then, you can easily refer to them in the text. Referring to figures and tables by name avoids any ambiguity that something like “the figure above” can introduce.

Make sure information in a given section or subsection of the report belongs there. Avoid restating information or reproducing the same graphic in later sections or subsections; instead, refer the reader back to the relevant part of the report (“As stated in Section 2.3, …” or, “These figures are given in Section 2.3.”).

Avoid cutting up sections at the end of a page, or stranding a graphic or equation on a page separate from the explanation. If only one line of a new section will fit at the end a page, move the whole section to the next page.

Definitely never split a table across two pages. If it is such a large table it doesn’t fit on one page, think carefully about whether it needs to be that large and contain that much information.

Many word processors default to spanning a table across the full page width, but most tables don’t need to be this large. They’re easier to read when more compact.

Generally, figures should be centered on the page with a caption centered below them. Italicizing the caption helps it stand out visually from the rest of the text. Consider the size of each figure: they should not be so small that details are difficult to discern, nor should they be larger than needed to clearly see all details, as that wastes space on the page.

Any block of code or terminal output (anything not included inline as part of a sentence) should be indented to stand out from the regular text. It may be placed in a numbered, captioned figure if it is important and/or if it is referred to somewhere other than immediately before or after the code.

Do not include code or a shell transcript as a screenshot of the code from a webpage, text editor, or terminal. Doing this produces a raster image of the text that will be low-resolution, pixelated, impossible to highlight and copy, and inaccessible to anyone using screen-reading software.

Blocks of code should be colored with syntax highlighting to improve readability. Avoid the temptation to just take a screenshot of the code from your syntax-highlighting editor, though. Some IDEs will produce code with syntax highlighting when you copy from them and paste into a word processor. There are also web-based syntax highlighters whose output can be copied and pasted into your word processor. ToHTML is one option; you might find another you like more. Shell transcripts do not need to be highlighted; there is no single language or syntax in use in a command line shell, so automatic coloring is difficult or impossible.

The Sheridan Libraries

• Computer Science and Information Security
• Sheridan Libraries

Technical Reports

• How to Access Full Text
• Background: Books and Review Articles
• Articles, Conferences, More
• Google Scholar and Google Books
• Information Security
• LaTeX, Overleaf, MATLAB, More
• Problems and Solutions
• Avoiding Plagiarism
• Citing Sources This link opens in a new window
• Copyright This link opens in a new window
• Evaluating Information This link opens in a new window
• Literature Reviews
• RefWorks Guide and Help This link opens in a new window
• CAPSTONE HELP

What's a "technical report" ?

A technical report is "an important means of... recording... the activities and the results of progress and research in... science and technology.

"Where once reports were simply the reporting of government-sponsored research, they are now used as a means of communicating information for technical development throughout the world."

[Report Series Codes Dictionary, 3rd edition, 1986]

Specialized Tech Report Collections

DTIC (Defense Technical Information Center)

• DTIC's publicly available collection of military reports and documents, going all the way back to the beginning of the 1900's, is available through Science.gov

NASA Technical Reports Server [1915+] -- This is a continually growing collection of information about NASA's current and historical research and engineering. It contains:

• NACA [National Advisory Committee for Aeronautics] information covers 1915-1958  
• NASA information covers 1958 to the present  
• NIX collection includes images, photos, movies, and videos downloaded from the NASA Image eXchange

For reports from the Jet Propulsion Lab , the best thing to do (after exhausting all other options) is to contact the library directly at [email protected] .

HISTORY OF NUCLEAR TECHNOLOGY

Los Alamos Technical Reports site -- In 2002, the Los Alamos National Laboratory (LANL) terminated public access to thousands of unclassified reports about nuclear science and technology.

Fortunately, almost all of the withdrawn reports were acquired and preserved so that the public has access to them.

How to Find and Get Technical Reports

National Technical Information Service (NTIS) [1964 to the present, with some info as far back as 1899] - NTIS is part of the U.S. Department of Commerce and is responsible for storing and disseminating technical reports generated from U.S. government-sponsored work. The database includes 3 million+ unclassified DoD, DoE, NASA, and other reports. NTIS reports can be searched in two ways:

• Search the National Technical Reports Library (NTRL)
• Search the NTIS database [this is easier]

To GET reports: Call or go to the GIS & Data Services office on A Level (410-516-8360), and ask to have an NTIS report ordered for you. This service is free of charge. Science.gov -- 200 million pages of science information and R&D results for 36+ U.S. government agencies.

• Search here for to get the list of specialized U.S. government databases available for searching
• Go here for the page that allows you to search across all of them at the same time

T RAIL (Technical Report Archive and Image Library) -- This site has detailed reports that include materials data, mathematical functions, time series, diffraction patterns, measurements, and much more. ata provided are from direct measurements.

WorldWideScience.org -- This web site, which also includes the information within Science.gov (listed above), is a gateway to national and international scientific databases. You can search resources from 17 countries, including Argentina, Australia, Brazil, Canada, Chile, Colombia, Denmark, France, Germany, Japan, the Netherlands, New Zealand, Portugal, Spain, South Africa, and the UK.

Reports Written by JHU Authors

Technical reports written by authors with JHU affiliations can be print or electronic.

• << Previous: Problems and Solutions
• Next: Writing and Citing >>
• Last Updated: Nov 7, 2023 12:41 PM
• URL: https://guides.library.jhu.edu/computer

Home > SCI > COMP_SCI > CSTECH

Department of Computer Science Technical Reports

Submit Technical Report Your TR # will be assigned by an administrator after your submission is made. If a TR # is needed prior to submission, please email your request to [email protected] . You will be notified by email as soon as your TR has been added to the site.

Submissions from 2021 2021

Data-Driven Abductive Inference of Library Specifications , Zhe Zhou, Robert Dickerson, Benjamin Delaware, and Suresh Jagannathan

Submissions from 2018 2018

Design and Implementation of an Efficient Parallel Feel-the-Way Clustering Algorithm on High Performance Computing Systems , Weijian Zheng, Fengguang Song, and Dali Wang (18-002)

Submissions from 2017 2017

Trojaning Attack on Neural Networks , Yingqi Liu, Shiqing Ma, Yousra Aafer, Wen-Chuan Lee, Juan Zhai, Weihang Wang, and Xiangyu Zhang (17-002)

syncope: Automatic Enforcement of Distributed Consistency Guarantees , Kiarash Rahmani, Gowtham Kaki, and Suresh Jagannathan (17-001)

Submissions from 2016 2016

A Testing Platform for Teaching Secure Distributed Systems Programming , Endadul Hoque, Hyojeong Lee, Charles Killian, and Cristina Nita-Rotaru (16-002)

Safe Memory Regions for Big Data Processing , Gowtham Kaki, G Ramalingam, Kapil Vaswani, and Dimitrios Vytiniotis (16-001)

Submissions from 2015 2015

vHaul: Towards Optimal Scheduling of Live Multi-VM Migration for Multi-tier Applications , Hui Lu, Cong Xu, Cheng cheng, Ramana Kompella, and Dongyan Xu (15-001)

Pay-as-you-go Feedback in Data Quality Systems , Romila Pradhan, Siarhei Bykau, and Sunil Prabhakar (15-003)

Declarative Programming over Eventually Consistent Data Stores , KC Sivaramakrishnan, Gowtham Kaki, and Suresh Jagannathan (15-002)

Submissions from 2014 2014

An Animation Stimuli System for Research on Instructor Gestures in Education , Jian Cui, Voicu Popescu, Nicoletta Adamo-Villan, Susan Cook, Katherine Duggan, and Howard Friedman (14-001)

Constructing Separating Halfspaces for Plane/Quadric and Quadric/Quadric Intersection , Christoph M. Hoffmann and Neelam Jasuja (14-003)

A Relational Framework for Higher-Order Shape Analysis , Gowtham Kaki and Suresh Jagannathan (14-002)

Composable Scheduler Activations for Haskell , KC Sivaramakrishnan, Tim Harris, Simon Marlow, and Simon Peyton Jones (14-004)

Submissions from 2013 2013

PG-PuReMD: A Parallel-GPU Reactive Molecular Dynamics Package , Sudhir B. Kylasa, Hasan Aktulga, and Ananth Grama (13-004)

Robust Polyhedral Minkowski Sums with GPU Implementation , Min-HO Kyung, Elisha P. Sacks, and Victor Milenkovic (13-001)

Systematic Identification of TOR Downstream Effectors Using Random-Walks on the Yeast Interactome , Shahin Mohammadi, Ananth Grama, and Shankar Subramaniam (12-011)

Technical Report: Increasing Network Resiliency by Optimally Assigning Diverse Variants to Routing Nodes , Andrew J. Newell, Daniel Obenshain, Thomas Tantillo, Cristina Nita-Rotaru, and Yair Amir (13-002)

Jumbo Frames or Not: That is the Question! , Pawan Prakash, Myungjin Lee, Y. Charlie Hu, Ramana Rao Kompella, Twitter Inc., and Twitter Inc. (13-006)

Robust Free Space Computation for Curved Planar Bodies , Elisha P. Sacks, Victor Milenkovic, and Steven Trac (13-003)

Submissions from 2012 2012

White Box Sampling in Uncertain Data Processing Enabled by Program Analysis , Tao Bao, Yunhui Zheng, and Xiangyu Zhang (12-002)

PhishLive: A View of Phishing and Malware Attacks from an Edge Router , Lianjie Cao, Thibaut Probst, and Ramana Kompella (12-007)

An ensemble model for collective classification that reduces learning and inference variance , Hoda Eldardiry and Jennifer Neville (12-003)

CobWeb: A System for Automated In-Network Cobbling of Web Service Traffic , Hitesh Khandelwal, Fang Hao, Sarit Mukherjee, Ramana Rao Kompella, and T.V. Lakshman (12-005)

Fast Parallel Algorithms for Graph Similarity and Matching , Georgios Kollias, Madan Sathe, Olaf Schenk, and Ananth Grama (12-010)

PuReMD-GPU: A Reactive Molecular Dynamic Simulation Package for GPUs , Sudhir B. Kylasa, Ananth Grama, and Hasan Aktulga (13-005)

Tied Kronecker Product Graph Models to Capture Variance in Network Populations , Sebastian Moreno, Jennifer Neville, and Sergey Kirshner (12-012)

Trustworthy Data from Untrusted Databases , Sunil Prabhakar and Rohit Jain (12-008)

Similarity-Aware Query Processing and Optimization , Yasin N. Silva, Walid G. Aref, Per-Ake Larson, and Mohamed H. Ali (12-006)

vSlicer: Latency-Aware Virtual Machine Scheduling via Differentiated-Frequency CPU Slicing , Cong Xu; Sahan Gamage; Oawab B, Rao; Ardalan Kangarlou; Ramana Rao Kompella; and Dongyan Xu (12-001)

Submissions from 2011 2011

Network Sampling via Edge-based Node Selection with Graph Induction , Nesreen Ahmed, Jennifer Neville, and Ramana Rao Kompella (11-016)

Using Past Queries for Resource Selection in Distributed Information Retrieval , Sulleyman Cetintas, Luo Si, and Hao Yuan (11-012)

On the Efficacy of Fine-Grained Traffic Splitting Protocols in Data Center Networks , Advait Dixit, Pawan Prakash, and Ramana Rao Kompella (11-011)

Opportunistic Flooding to Improve TCP Transmit Performance in Virtualized Clouds , Sahan Gamage, Ardalan Kangarlou, Ramana Rao Kompella, and Dongyan Xu (11-014)

c-Lock: Dynamic Lock-coalescing for Latency-sensitive Distributed Locking , Adnan Hassan, Naresh Rapolu, Ananth Y. Grama, and Wojciech Szpankowski (11-008)

Geometric Interoperability for Resilient Manufacturing , Christoph M. Hoffmann, Vadim Shapiro, and Vijay Srinivasan (11-015)

Network Similarity Decomposition (NSD): A Fast and Scalable Approach to Network Alignment , Giorgos Kollias, Ananth Y. Grama, and Shahin Mohammadi (11-001)

Leave Them Microseconds Alone: Scalable Architecture for Maintaining Packet Latency Measurements , Myungjin Lee, Nick Duffield, and Ramana Rao Kompella (11-013)

Structured Comparative Analysis of Systems Logs to Diagnose Performance Problems , Karthik Nagaraj, Jennifer Neville, and Charles Killian (11-020)

Query Processing in Private Data Outsourcing Using Anonymization , Ahmet Erhan Nergiz and Chris Clifton (11-004)

Methods to Determine Node Centrality and Clustering in Graphs with Uncertain Structure , Joseph J. Pfeiffer III and Jennifer Neville (11-010)

The TCP Outcast Problem: Exposing Unfairness in Data Center Networks , Pawan Prakash, Advait Dixit, Y. Charlie Hu, and Ramana Rao Kompella (11-019)

Featherweight Threads for Communication , KC Sivaramakrishnan, Lukasz Ziarek, and Suresh Jagannathan

Detecting Inconsistencies in Private Data with Secure Function Evaluation , Nilothpal Talukder, Mourad Ouzzani, Ahmed K. Elmagarmid, and Mohamed Yakout (11-006)

Privacy Preserving Regression Residual Analysis , John Ross Wallrabenstein and Chris Clifton (11-017)

Accentuating the Positive: Atomicity Inference and Enforcement Using Correct Executions , Dasarath Weeratunge, Xiangyu Zhang, and Suresh Jagannathan (11-002)

Sparse Matrix-variate t Process Blockmodels , Zenglin Xu, Feng Yan, and Yuan Qi (11-005)

Submissions from 2010 2010

vSnoop: Improving TCP Throughput in Virtualized Environments via Acknowledgement Offload , Ardalan Kangarlou, Sahan Gamage, Ramana Rao Kompella, and Dongyan Xu (10-003)

One Stack to Run Them All Reducing Concurrent Analysis to Sequential Analysis Under Priority Scheduling , Nicholas Kidd, Suresh Jagannathan, and Jan Vitek (10-005)

FineComb: Measuring Microscopic Latencies and Losses in the Presence of Reordering , Myungjin Lee, Sharon Goldberg, Ramana Rao Kompella, and George Varghese (10-009)

Revisiting Overlay Multicasting for the Cloud , Karthik Nagaraj, Hitesh Khandelwal, Charles Killian, and Ramana Rao Kompella (10-011)

Path-Sensitive Analysis Using Edge Strings , Armand Navabi, Nicholas Kidd, and Suresh Jagannathan (10-006)

Generalizations with Probability Distributions for Data Anonymization , Mehmet Ercan Nergiz, Suleyman Cetintas, Ahmet Erhan Nergiz, and Ferit Akova (10-013)

Correcting Bias in Statistical Tests for Network Classifier Evaluation , Jennifer Neville, Tao Wang, Brian Gallagher, and Tina Eliassi-Rad (10-012)

Transactional Support in MapReduce for Speculative Parallelism , Naresh Rapolu, Karthik Kambatla, Suresh Jagannathan, and Ananth Y. Grama (10-001)

Memory Indexing and its Use in Automated Debugging , William Summer and Xiangyu Zhang (10-010)

Analyzing Concurrency Bugs Using Dual Slicing , Dasarath Weeratunge, Xiangyu Zhang, William Summer, and Suresh Jagannathan

Lightweight Task Graph Inference for Distributed Applications , Bin Xin, Patrick Eugster, Xiangyu Zhang, and Jinlin Yang (10-002)

Isolates: Serializability Enforcement for Concurrent ML , Lukasz Ziarek, Armand Navabi, and Suresh Jagannathan (10-007)

Composable Asynchronous Events , Lukasz Ziarek, KC Sivaramakrishnan, and Suresh Jagannathan (10-008)

Submissions from 2009 2009

Supporting Real-world Activities in Database Management Systems , Mohamed Eltabakh, Walid G. Aref, Ahmed K. Elmagarmid, Yasin Laura-Silva, and Mourad Ouzzani (09-001)

On the Modification of an Eigenvalue Problem that Preserves an Eigenspace , Maxim Maumov (09-004)

A Statistical Method for Integrated Data Cleaning and Imputation , Chris Mayfield, Jennifer Neville, and Sunil Prabhakar (09-008)

Homomorphic Encryption based k-out-of-n Oblivious Transfer Protocols , Mummoorthy Murugesan, Wei Jiang, Erhan Nergiz, and Serkan Uzunbaz (09-007)

Non-Pinhole Imposters , Voicu Popescu, Kyle Hayward, Paul Rosen, and Chris Wyman (09-006)

Identifying Interesting Instances for Probabilistic Skylines , Yinian Qi and Mikhail J. Atallah (09-009)

A Network-Aware Distributed Membership Protocol for Collaborative Defense , David Zage, Carl Livadas, and Eve M. Schooler (09-005)

Submissions from 2008 2008

Interactive Reconfiguration of Urban Layouts , Daniel G. Aliaga, Bedrich Benes, Carlos A. Vanegas, and Nathan Andrysco (08-003)

Energy-Efficient Peer-to-Peer Caching and Mobility Management in 4G Hybrid Networks , Mehdi Azami and Bharat Bhargava (08-030)

Accurate Localization of Low-level Radioactive Source Under Noise and Measurement Errors , Jren-Chit Chin, David K.Y. Yau, Nageswara S. V. Rao, Yong Yang, and Chris Y.T. Ma (08-012)

Secure High-Throughput Multicast Routing in Wireless Mesh Networks , Jing Dong, Reza Burtmola, and Cristina Nita-Rotaru (08-014)

Preserving Privacy and Fairness in Peer Data Management Systems , Hazen Elmeleegy, Ahmed Abusalah, Mourad Ouzzani, and Ahmed K. Elmagarmid (08-025)

Chameleon: Context-Awareness inside DBMSs , Hicham G. Elmongui, Walid G. Aref, and Mohamed F. Mokbel (08-028)

Incremental Mining for Frequent Patterns in Evolving Time Series Datatabases , Mohamed Y. Eltabakh, Mourad Ouzzani, Mohamed A. Khalil, Walid G. Aref, and Ahmed K. Elmagarmid (08-020)

Elimination of Subjectivity from Trust Recommendation , Omas Hasan, Lionel Brunie, Jean-Marc Pierson, and Elisa Bertino (08-008)

t-Plausibility: Semantic Preserving Text Sanitization , Wei Jiang, Mummoorthy Murugesan, Chris Clifton, and Luo Si (08-024)

The Decay Rate of the Solution to a Tridiagonal Linear System With A Very Special Right Hand Side , Carl Christian Kjelgaard Mikkelsen (08-021)

Practical Strengthening of Preconditions , Ashish Kundu and Patrick Eugster (08-029)

AjaxTracker: A Tool for High Fidelity Characterization of Ajax Applications , Myungjin Lee, Sumeet Singh, and Ramana Rao Kompella (08-019)

Deriving Input Syntactic Structure From Execution and Its Applications , Zhiqiang Lin and Xiangyu Zhang (08-006)

Exceptionally Safe Futures , Armand Navabi and Suresh Jagannathan (08-027)

Self-tuning Query Mesh for Adaptive Multi-Route Query Processing , Rimma V. Nehme, Elke A. Rundersteiner, and Elisa Bertino (08-018)

Query Mesh: An Efficient Multi-Route Approach to Query Optimization , Rimma V. Nehme, Karen Works, Elke A. Rundensteiner, and Elisa Bertino (08-009)

Towards Trajectory Anonymization: A Generalization-Based Approach , Mehmet Ercan Nergiz, Maurizo Atzori, and Yucel Saygin (08-015)

Generalizations with Probability Distributions for Data Anonymization , M. Ercan Nergiz, Suleyman Cetintas, and Ferit Akova (08-001)

S-Presence Without Complete World Knlowedge , M. Ercan Nergiz and Chris Clifton (08-016)

MultiRelational k-Anonymity , N. Ercan Nergiz, Chris Clifton, and A. Erhan Nergiz (08-002)

The Graph Camera , Paul Rosen, Voicu Popescu, and Nicoletta Adamo-Villani (08-005)

A Framework for Efficient Class-based Sampling , Mohit Saxena and Ramana Rao Kompella (08-022)

'Won't You Be My Neighbor?' Neighbor Selection Attacks in Mesh-based Peer-to-Peer Streaming , Jeff Seibert, Davied Zae, Sonia Fahmy, and Cristina Nita-Rotaru (08-004)

Automatic Failure Inducing Chain Computation through Aligned Execution Comparison , William N. Sumner and Xiangyu Zhang (08-023)

Record Linkage Based on Entities' Behavior , Mohamed Yakout, Ahmed K. Elmagarmid, Hazen Elmeleegy, and Mourad Ouzzani (08-026)

Quality of Monitoring of Stochastic Events by Proportional-Share Mobile Sensor Coverage , David K.Y. Yau, Nung Kwan Yip, Chris Y. T. Ma, Nageswara S. Rao, and Mallikarjun Shankar (08-011)

Fibonacci Modeling of Malware Propagation , Yu Zhang and Bharat Bhargava (08-017)

Submissions from 2007 2007

This message will self-destruct: Self-easing covert communication , Mikhail J. Atallah, Mercan Topkara, and Umut Topkara (07-011)

Scalable Data Collection in Dense Wireless Sensor Networks , Asad Awan, Suresh Jagannathan, and Ananth Y. Grama (07-018)

BSMR: Byzantine-Resilient Secure Multicast Routing in Multi-hop Wireless Networks , Reza Curtmola and Cristina Nita-Rotaru (07-005)

Virtual Classroom Extension for Effective Distance Education , Radu Dondera, Chun Jia, Voicu Popescu, Cristina Nita-Rotaru, and Melissa Dark (07-001)

Securing Virtual Coordinate System Based Routing in Wireless Sensor Networks , Jing Dong, Brett Bavar, and Cristina Nita-Rotaru (07-009)

Enabling Confidentiality for Group Communication in Wireless Mesh Networks , Jing Dong and Cristina Nita-Rotaru (07-010)

Supporting annotated Relations , M. Y. Eltabakh, M. Ouzzani, Walid G. Aref, Ahmed K. Elmagarmid, and Y. Laura-Silva (07-025)

Page 1 of 18

Advanced Search

• Notify me via email or RSS
• Purdue Libraries
• Purdue University Press Open Access Collections

Links for Authors

• Policies and Help Documentation
• Submit Research
• Collections
• Disciplines

Home | About | FAQ | My Account | Accessibility Statement

Privacy Copyright