When you try to exit a window or logout, you may get a message:
There are stopped jobs.
This means that a program you were running has been suspended (usually by
typing Ctrl-Z) and has not been properly terminated. If you just try to exit
again, the system will automatically terminate those jobs. If you want to see
what those jobs are, use the 'jobs' command. Just type:
jobs
You will see a listing, which may look like this:
[1] - Stopped foo
[2] + Stopped bar
If you want to continue using one of the jobs in the list, use the 'fg'
command. For example, if you wanted to continue using 'foo' in the above
listing, type this:
fg %1
Actually, the 'fg' part is optional. So, you could just type:
%1
...and get the same effect. If instead you want to just terminate a job, use
the 'kill' command. For example, if you wanted to kill 'bar' in the above
listing, type this:
kill %2
The information below describes jobs in much more detail, if you're
interested.
The shell associates a job with each pipeline (most often a single
command/program) It keeps a table of current jobs, printed by the "jobs"
command, and assigns them small integer numbers. When a job is started
asynchronously with '&' (started in the background), the shell prints a line
which looks like:
[1] 1234
indicating that the job that was started asynchronously was job number 1 and
had one (top-level) process, whose process ID number was 1234.
If you are running a job and wish to do something else, you may type Ctrl-Z,
which sends a STOP signal to the current job. The shell will then normally
indicate that the job has been 'Stopped', and print another prompt. You can
then manipulate the state of this job, putting it in the background with the
'bg' command, or run some other commands and then eventually bring the job
back into the foreground with the foreground command 'fg'. A Ctrl-Z takes
effect immediately and is like an interrupt in that pending output and unread
input are discarded when it is typed. There is another special key, Ctrl-Y,
which does not generate a STOP signal until a program attempts to read(2) it.
This can be typed ahead when you have prepared some commands for a job which
you wish to stop after it has read them.
A job being run in the background will stop if it tries to read from the
terminal. Background jobs are normally allowed to produce output, but this
can be disabled by giving the command 'stty tostop'. If you set this tty
option, then background jobs will stop when they try to produce output like
they do when they try to read input.
There are several ways to refer to jobs in the shell. The character '%'
introduces a job name. If you wish to refer to job number 1, you can name it
as '%1'. Just naming a job brings it to the foreground; thus '%1' is a
synonym for 'fg %1', bringing job 1 back into the foreground. Similarly
saying '%1 &' resumes job 1 in the background. Jobs can also be named by
prefixes of the string typed in to start them, if these prefixes are
unambiguous, thus '%ex' would normally restart a suspended ex(1) job, if there
were only one suspended job whose name began with the string 'ex'. It is also
possible to say '%?string' which specifies a job whose text contains string,
if there is only one such job.
The shell maintains a notion of the current and previous jobs. In output
pertaining to jobs, the current job is marked with a '+' and the previous job
with a '-'. The abbreviation '%+' refers to the current job and '%-' refers
to the previous job. For close analogy with the syntax of the history
mechanism, '%%' is also a synonym for the current job.
The notes below apply to technical papers in computer science and electrical engineering, with emphasis on papers in systems and networks.
Read Strunk and White, Elements of Style. Again.
Give the paper to somebody else to read. If you can, find two people: one person familiar with the technical matter, another only generally familiar with the area.
Papers can be divided roughly into two categories, namely original research papers and survey papers. There are papers that combine the two elements, but most publication venues either only accept one or the other type or require the author to identify whether the paper should be evaluated as a research contribution or a survey paper. (Most research papers contain a "related work" section that can be considered a survey, but it is usually brief compared to the rest of the paper and only addresses a much narrower slice of the field.)
A good research paper has a clear statement of the problem the paper is addressing, the proposed solution(s), and results achieved. It describes clearly what has been done before on the problem, and what is new.
The goal of a paper is to describe novel technical results. There are four types of technical results:
One goal of the paper is to ensure that the next person who designs a system like yours doesn't make the same mistakes and takes advantage of some of your best solutions. So make sure that the hard problems (and their solutions) are discussed and the non-obvious mistakes (and how to avoid them) are discussed. (Craig Partridge)
The body should contain sufficient motivation, with at least one example scenario, preferably two, with illustrating figures, followed by a crisp generic problem statement model, i.e., functionality, particularly emphasizing "new" functionality. The paper may or may not include formalisms. General evaluations of your algorithm or architecture, e.g., material proving that the algorithm is O(log N), go here, not in the evaluation section.
Architecture of proposed system(s) to achieve this model should be more generic than your own peculiar implementation. Always include at least one figure.
Realization: contains actual implementation details when implementing architecture isn't totally straightforward. Mention briefly implementation language, platform, location, dependencies on other packages and minimum resource usage if pertinent.
Evaluation: How does it really work in practice? Provide real or simulated performance metrics, end-user studies, mention external technology adoptors, if any, etc.
It is recommended that you write the approach and results sections first, which go together. Then problem section, if it is separate from the introduction. Then the conclusions, then the intro. Write the intro last since it glosses the conclusions in one of the last paragraphs. Finally, write the abstract. Last, give your paper a title.
Use adjectives that describe the distinctive features of your work, e.g., reliable, scalable, high-performance, robust, low-complexity, or low-cost. (There are obviously exceptions, e.g., when the performance evaluation is the core of the paper. Even in that case, something more specific is preferable, as in "Delay measurements of X" or "The quality of service for FedEx deliveries".)
The IEEE affirms that authorship credit must be reserved for individuals who have met each of the following conditions: 1) made a significant intellectual contribution to the theoretical development, system or experimental design, prototype development, and/or the analysis and interpretation of data associated with the work contained in the manuscript, 2) contributed to drafting the article or reviewing and/or revising it for intellectual content, and 3) approved the final version of the manuscript, including references.
This has now moved to the IEEE PSPB Operations Manual, Section 8.2.1.
Here at the institute for computer research, me and my colleagues have created the SUPERGP system and have applied it to several toy problems. We had previously fumbled with earlier versions of SUPERGPSYSTEM for a while. This system allows the programmer to easily try lots of parameters, and problems, but incorporates a special constraint system for parameter settings and LISP S-expression parenthesis counting.
The search space of GP is large and many things we are thinking about putting into the supergpsystem will make this space much more colorful.
Many new domains for genetic programming require evolved programs to be executed for longer amounts of time. For example, it is beneficial to give evolved programs direct access to low-level data arrays, as in some approaches to signal processing \cite{teller5}, and protein segment classification \cite{handley,koza6}. This type of system automatically performs more problem-specific engineering than a system that accesses highly preprocessed data. However, evolved programs may require more time to execute, since they are solving a harder task.
- Previous or obvious approach:
- (Note that you can also have a related work section that gives more details about previous work.)) One way to control the execution time of evolved programs is to impose an absolute time limit. However, this is too constraining if some test cases require more processing time than others. To use computation time efficiently, evolved programs must take extra time when it is necessary to perform well, but also spend less time whenever possible.
- Approach/solution/contribution:
- The first sentence of a paragraph like this should say what the contribution is. Also gloss the results.
In this chapter, we introduce a method that gives evolved programs the incentive to strategically allocate computation time among fitness cases. Specifically, with an aggregate computation time ceiling imposed over a series of fitness cases, evolved programs dynamically choose when to stop processing each fitness case. We present experiments that show that programs evolved using this form of fitness take less time per test case on average, with minimal damage to domain performance. We also discuss the implications of such a time constraint, as well as its differences from other approaches to {\it multiobjective problems}. The dynamic use of resources other than computation time, e.g., memory or fuel, may also result from placing an aggregate limit over a series of fitness cases.
- Overview:
- The following section surveys related work in both optimizing the execution time of evolved programs and evolution over Turing-complete representations. Next we introduce the game Tetris as a test problem. This is followed by a description of the aggregate computation time ceiling, and its application to Tetris in particular. We then present experimental results, discuss other current efforts with Tetris, and end with conclusions and future work.
John Doe, "Some paper on something", technical report.are useless. Cite the source, date and other identifying information.
Jane Doe, "Some random paper", to be published, 2003.is useless, as the paper has presumably been published by now. Google or the ACM or IEEE digital libraries will help you find it.
In all but extended abstracts, numerical results and simulations should be reported in enough detail that the reader can duplicate the results. This should include all parameters used, indications of the number of samples that contributed to the analysis and any initial conditions, if relevant.
When presenting simulation results, provide insight into the statistical confidence. If at all possible, provide confidence intervals. If there's a "strange" behavior in the graph (e.g., a dip, peak or change in slope), this behavior either needs to be explained or reasons must be given why this is simply due to statistical aberration. In the latter case, gathering more samples is probably advised.
Figures should be chosen wisely. You can never lay out the whole parameter space, so provide insight into which parameters are significant over what range and which ones are less important. It's not very entertaining to present lots of flat or linear lines.
The description of the graph should not just repeat the graphically obvious such as "the delay rises with the load", but explain, for example, how this increase relates to the load increase. Is it linear? Does it follow some well-known other system behaviors such as standard queueing systems?
x_{\mathrm max}
\usepackage{graphics}
...
\begin{figure}
\resizebox{!}{0.5\textheight}{\includegraphics{foo.eps}}
\caption{Some figure}
\label{fig:figure}
\end{figure}
From Bill Stewart (Slashdot, May 7, 2006), edited
- Write like a newspaper reporter, not a grad student.
- Your objective is clear communication to the reader, not beauty or eruditeness or narration of your discoveries and reasoning process. Don't waste their time, or at least don't waste it up front.
- Hit the important conclusions in the first few sentences so your reader will read them. If you'd like to wrap up with them at the end of your memo, that's fine too, in case anybody's still reading by then, but conclusions come first.
- If you're trying to express something complex, simplify your writing so it doesn't get in the way. For something simple, 10th grade language structures will do, but if it's really hairy stuff, back down to 8th grade or so.
- Think about what your audience knows and doesn't know, and what they want and don't want. Express things in terms of what they know and want, not what you know.
From MarkusQ, Slashdot, May 7, 2006
- Top down design Starting with an outline and working out the details is the normal way of tackling an engineering problem.
- Checking your facts Engineers should be used to checking anything that is even remotely doubtful before committing to it. So should writers.
- Failure mode analysis For each sentence ask yourself, could it be misread? How? What is the best way to fix it?
- Dependency analysis Are the ideas presented in an order that assures that each point can be understood on the basis of the readers assumed knowledge and the information provided by preceding points?
- Optimization Are there any unnecessary parts? Does the structure require the reader to remember to many details at once, before linking them?
- Structured testing If you read what you have written assuming only the knowledge that the reader can be expected to have, does each part work the way you intended? If you read it aloud, does it sound the way you intended?
It is hard to generalize the review process for conferences, but most reputable conferences operate according to these basic rules:
This is an amazing little book that you can read in a few hours. Your writing style will never be the same afterwards. This $8 book is the best investment you can ever make.
This is a great book that expands on Strunk&White. It has more examples, and was written by an author who edited numerous technical publications, many of which were in computer science.
This is the bible for American academic style. It's long and heavy, but has everything you ever want to know about style. When in doubt, or if you get conflicting stylistic advice, following The Chicago Manual of Style is your best choice.
This is another useful book written for publishing (computer) scientists.
This is a useful article that teaches scientists how to write single sentences and paragraphs, such as "follow a grammatical subject as soon as possible with its verb" and "articulate the action of every clause or sentence in its verb".
It is an extensive resource explaining how to write papers, reports, memoranda and Ph.D. thesis, how to make high-performance slides and oral presentations, how to avoid common pitfalls and mistakes in English, etc., with many examples of "good" and "bad" practices.
Generally useful advice that also applies to other networking conferences.
typedef int (__stdcall *CompareFunction)(const byte*, const byte*);
void DLLDIR __stdcall Bubblesort(byte* array,
int size,
int elem_size,
CompareFunction cmpFunc);
void DLLDIR __stdcall Quicksort(byte* array,
int size,
int elem_size,
CompareFunction cmpFunc);
These two functions take the following parameters:
void DLLDIR __stdcall Bubblesort(byte* array,
int size,
int elem_size,
CompareFunction cmpFunc)
{
for(int i=0; i < size; i++)
{
for(int j=0; j < size-1; j++)
{
// make the callback to the comparison function
if(1 == (*cmpFunc)(array+j*elem_size,
array+(j+1)*elem_size))
{
// the two compared elements must be interchanged
byte* temp = new byte[elem_size];
memcpy(temp, array+j*elem_size, elem_size);
memcpy(array+j*elem_size,
array+(j+1)*elem_size,
elem_size);
memcpy(array+(j+1)*elem_size, temp, elem_size);
delete [] temp;
}
}
}
}
Note: Because the implementation uses memcpy(), these library functions should not be used for types other than POD (Plain-Old-Data).
int __stdcall CompareInts(const byte* velem1, const byte* velem2)
{
int elem1 = *(int*)velem1;
int elem2 = *(int*)velem2;
if(elem1 < elem2)
return -1;
if(elem1 > elem2)
return 1;
return 0;
}
int __stdcall CompareStrings(const byte* velem1, const byte* velem2)
{
const char* elem1 = (char*)velem1;
const char* elem2 = (char*)velem2;
return strcmp(elem1, elem2);
}
int main(int argc, char* argv[])
{
int i;
int array[] = {5432, 4321, 3210, 2109, 1098};
cout << "Before sorting ints with Bubblesort\n";
for(i=0; i < 5; i++)
cout << array[i] << '\n';
Bubblesort((byte*)array, 5, sizeof(array[0]), &CompareInts);
cout << "After the sorting\n";
for(i=0; i < 5; i++)
cout << array[i] << '\n';
const char str[5][10] = {"estella",
"danielle",
"crissy",
"bo",
"angie"};
cout << "Before sorting strings with Quicksort\n";
for(i=0; i < 5; i++)
cout << str[i] << '\n';
Quicksort((byte*)str, 5, 10, &CompareStrings);
cout << "After the sorting\n";
for(i=0; i < 5; i++)
cout << str[i] << '\n';
return 0;
}
If you don't like the word __stdcall, you can use the CALLBACK macro, defined in windef.h, as
Your cron job looks like as follows:
1 2 3 4 5 /path/to/command arg1 arg2
Where,
Same above five fields structure can be easily remembered with following diagram:
* * * * * command to be executed
- - - - -
| | | | |
| | | | ----- Day of week (0 - 7) (Sunday=0 or 7)
| | | ------- Month (1 - 12)
| | --------- Day of month (1 - 31)
| ----------- Hour (0 - 23)
------------- Minute (0 - 59)
An operator allows you to specifying multiple values in a field. There are three operators: