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.