Submitting articles to The Mathematica Journal
- To: mathgroup at smc.vnet.net
- Subject: [mg9212] Submitting articles to The Mathematica Journal
- From: Nancy Blachman <nb at dnai.com>
- Date: Fri, 24 Oct 1997 01:00:28 -0400
- Sender: owner-wri-mathgroup at wolfram.com
Here are the current guidelines for submitting articles to The
Mathematica Journal.
Nancy Blachman
Co-Editor, The Mathematica Journal
*************************************************************************
THE MATHEMATICA JOURNAL
GUIDELINES FOR SUBMISSIONS
GENERAL INFORMATION
The Mathematica Journal publishes articles and notes on all aspects of
Mathematica and related subjects. Our goal is to inform and challenge
the community of Mathematica users and especially to enable readers at
all levels of proficiency to use Mathematica more effectively. Toward
this end, we encourage a high standard of Mathematica programming and
clarity and conciseness in writing. In particular, we reserve the right
to edit contributions (with changes subject to the authors' approval).
The Journal also publishes, in an electronic supplement, Mathematica
packages and notebooks, as well as programs in other languages that can
be used to complement Mathematica in various ways. All programs are
accompanied by a note or article in the printed component, since not
all readers have access to the electronic supplement. Programs
distributed through the Journal can be used freely and duplicated for
noncommercial purposes, according to the Software License Agreement
found near the beginning of each issue.
We list here the categories of material that are published most
frequently, together with the main criteria of publishability in each
category. This list is not considered exhaustive.
* Reports of applications of Mathematica to particular fields in
education, research, or business. The level of exposition should be
such that readers from other fields can grasp the essence of the
application, the reasons why Mathematica is being used, and the
possible relevance to other fields of the techniques being employed.
At the same time, the article should not be trivial from the point of
view of a reader in the field.
* Descriptions of programs - Mathematica packages and notebooks or
Mathematica-related programs in other languages - whether or not
accompanied by the code itself. The programs should be exemplary in
their implementation and thoroughly tested. See below for more
guidelines on packages and notebooks.
* Mathematica programming advice. This can range from notes about
little-known programming tricks to tutorials focusing on a general
problem or technique. The main test of publishability here is how many
readers are likely to benefit from the ideas discussed, but even a
relatively esoteric application can serve as a vehicle for the
teaching of good programming principles.
* Discussion of issues beyond Mathematica per se. Essays, columns, and
surveys on subjects that do not involve Mathematica directly are
welcome - so long as they're likely to be of general interest to the
Mathematica community. Possible subjects include, but are not limited
to, symbolic computation, numerical computation, computer-based
education, computer graphics, and computer art. Articles of this type
should be particularly well written and well argued, and their
relevance to the Mathematica community should be clear.
To submit a contribution, send four copies of the manuscript, together
with a cover letter stating that it is being submitted for publication
in The Mathematica Journal, to
The Mathematica Journal
Editorial Office
525 B Street Suite 1900
San Diego, California 92101-4495
Packages, notebooks, and programs submitted for publication in the
electronic component should be submitted on a 3 1/2-inch diskette in
Macintosh, DOS, or UNIX format. Authors are encouraged to send their
text in electronic form as well, but in all cases, the diskettes should
be accompanied by hard copy. The preferred electronic format for
articles is a Mathematica notebook or LaTeX file. Submissions will not
be returned. Do not send proprietary or confidential information.
GUIDELINES FOR TEXT
Manuscripts must be in English, typed, and double-spaced on one side of
the page only. Manuscripts should contain:
1. The title
2. Your name(s), affiliation, postal, and (if available) electronic
mail address
3. An abstract of at most 150 words
4. References
5. A list of accompanying electronic material, including, if
appropriate, information on the necessary environment (machine,
operating system, and so on)
6. A biography of each author, limited to 60 words per author and 180
words overall.
Avoid footnotes if possible. If used, they should be numbered
sequentially and clearly marked in the text. The text may be divided
into (unnumbered) sections; subsections and subsubsections should be
avoided.
REFERENCES
References should include full information: author or institution; full
title; and publisher, city, and year (for books, manuals, and so on),
or full journal name, volume, year, and page range (for papers).
References to software and hardware should contain complete
manufacturer's or distributor's names and addresses. Citations should
be indicated in the text in the form [Charles and Glaser 1997; Blachman
1990]. All references in the bibliography should be cited in the text
or accompanied by comments stating their relevance. Do not include
Stephen Wolfram's Mathematica Book as a general source, since readers
are expected to be familiar with it.
FIGURES
Figures generated electronically must be submitted in hard copy together
with the text, and you must be prepared to supply an electronic version
if your article is accepted for publication. If you created your
graphics with Mathematica itself, you may simply submit your notebook
or package directly. A number of illustration tools also produce
acceptable electronic copy, notably Adobe Illustrator. Bitmap images
and images that cannot be edited are unacceptable. When in doubt, check
with the editor. Black-and-white and color photographs must be of
reproduction quality; they should be mounted on 8 1/2 x 11 inch
cardboard. Hand-drawn vellums are also acceptable; the original and
three clear copies should accompany the four copies of the text.
STYLE AND CONTENTS
Naturally, writing style depends on the type of submission and the
author, but in all cases, papers should be concisely written and well
organized, with the flow of ideas summarized in an introduction and
made clear by the use of connectives. Although packages and notebooks
will only appear in the electronic supplement, the inclusion of short
excerpts of code and interactive Mathematica sessions is encouraged.
Please follow these guidelines for text and embedded code:
* Use of the word Mathematica should be kept to a minimum, since the
reference is almost always clear from the context. It is especially
discouraged in titles.
* Technical terms unlikely to be known to non-specialists should be
italicized the first time they are used, and, unless the first use is
self-explanatory, they should be defined or explained then.
* Mathematica words, symbols or expressions should appear in a font
distinct from that used for text. The use of a fixed-pitch font, in
which all characters have the same width, is strongly encouraged.
"Metavariables" or placeholders, like args and opts in
DoWhatIMean[args, opts]
may or may not be indicated by the use of a special font, but such use
should be consistent throughout the article.
* References to Mathematica functions should not be followed by [],
unless what is meant is that the function is being invoked with no
arguments.
* Lines of displayed code, whether from packages or interactive
sessions, should be no longer than 55 characters.
* In interactive Mathematica sessions, do not use % to refer to
previous lines by number (as in Show[%10]). It is acceptable to use %
and %% to refer to the previous two lines.
* Do not use Mathematica comments in interactive sessions; instead,
alternate explanatory text with input-output pairs. It is especially
important to explain the commands in a long interactive session as you
go along, rather than all at once at the beginning or end of the
session. As a rule, notebooks should be cast into this same format:
explanatory text alternating with code.
* Always mention what version of Mathematica you are running.
GUIDELINES FOR MATHEMATICA PACKAGES
Packages are programs written in Mathematica, to be used on their own or
integrated with the user's code. Packages submitted for publication in
the electronic supplement should be accompanied by a self-contained
article or note for the printed component.
The single most important consideration in designing a Mathematica
package for distribution is that it must be readily usable by others.
Clarity is the goal, and a good test of the clarity of your design is
the ease with which it can be documented. Ideally, the purpose and use
of each symbol visible to the user should be simple enough to explain
in its ::usage string.
The simpler the description of your design, the more likely people will
understand and use what you have built. In addition, designs that are
short to describe are often more general and therefore usable in a
wider range of circumstances.
The book Programming in Mathematica 3rd ed., by Roman Maeder
(Addison-Wesley, 1996) provides good pointers on programming style and
discusses the material in the next few paragraphs in more detail.
NAMING
Follow the general naming convention used in Mathematica: Names should
be full English words, or sequences of words concatenated together.
When in doubt, use the longer or more explicit term; avoid
nondescriptive abbreviations and names.
PROGRAMMING STYLE
Use transformation rules and functional programming as much as possible;
procedural programming is less efficient, longer, and more difficult to
understand in Mathematica. A surprisingly large fraction of
mathematical operations can be programmed much more neatly using
transformation rules than procedural programming, although sometimes it
can take a while to see how to do it. The time spent is almost always
worth it.
MODULARITY
Avoid using global variables whenever possible; use options instead.
Define all symbols - functions, options, variables, and so on - in
appropriate Mathematica contexts.
Think about how your functions will fit with other functions a person
will be using. Will the input for your functions be easy to obtain from
other Mathematica functions? Will their output be readily amenable to
further processing? Try to make sure your package can be used as part
of a "pipeline," rather than only as a stand-alone application.
DOCUMENTATION
All symbols visible outside your package must be documented with ::usage
statements; error and warning messages should be provided in
anticipation of mistakes and should be as explicit as possible. Use of
comments for internal documentation is encouraged (see also the section
on notebooks). As a special case of internal documentation, your
package must have certain comments in a standardized format, containing
title, author names, version number, and so on. Other information, such
as sources and description of algorithms, is optional but strongly
encouraged. The electronic supplement contains an example package
enumerating these required and optional fields.
PORTABILITY ISSUES
The Macintosh PICT graphics format works only on Macintosh computers.
Because of this restriction, notebooks containing pictures pasted in
from other Mac applications are not portable to other systems. You
should convert such pictures into a portable form using the Convert to
PostScript menu command.
PROOFS AND REPRINTS
Proofs will be sent to the corresponding author. The publisher will
provide 25 reprints without covers of each article free of charge.
Authors may purchase additional reprints; an order form will be
included with the proofs.