libmdate

a Mayan date library

for version 0.0.4, 3 June 2000

Overview

libmdate is currently a library to output the current date in Mayan calendar format using a Julian DAy Number JDN correlation, and dates in three formats may be entered to output a desired date.

The purpose of libmdate is to provide an all-round utility/library to convert from/to Mayan calendar dates. It is intended that libmdate be used to port to comfortable GUI interfaces in the near future, as well as provide a hopefully useful library API to build upon.

Mdate was first coded in 1998 by Sean Dwyer as an implementation of the Dershowitz/Reingold algorithms in their book Calendrical Calculations. Since then libmdate has been created, and is still to my knowledge the only freely-available C implementation of a Mayan calendar library.

This manual also documents the current command-line implementation of libmdate, Mdate itself, as a simple demonstration of the library's capabilities.

libmdate is now being developed by the Mdate Development Team, and their home is at http://mdate.sourceforge.net.

More functionality to come.

Syntax

The console version of libmdate (so far the only version) uses a number of options which are documented here:

Note: so far the console mdate does not support standard GNU utilities option syntax. It may be added in a future command-line version if people really want it, but I think it unnecessary for the time being.

Simple Options

These options are the most basic.

`-h'

Prints help screen and exits.

`-?'

Prints a usage message and exits.

`-v'

Displays the program's current version and exits.

`-p'

Alone, or in conjunction with date input, outputs a single line of Mayan calendar data instead of the normal multi-line display.

Date-entry Options

The command-line mdate has a few methods for entering dates, depending on the data you require. You can access all the date fields excepting the Tzolkin and Haab dates for each option.

Current date

Simply put, getting the current date is as simple as typing mdate on the command line. Depending on whether you use the program-parseable flag, you will get either a one-line output or a multi-line output giving you the current date, Julian Day Number (herafter abbreviated as JDN), Long Count and Mayan date in Tzolkin and Haab calendars.

Examples of output:

One-line output:

JDN: 2451625.0 date: 21 03 2000 12.19.07.01.00 11 Ahau 08 Cumku

Multi-line output:

Gregorian Date          : 21-March-2000 (21/3/2000)
Julian Day Number       : 2451625.0
Long Count              : 12.19.07.01.00 
Tzolkin Date            : 11 Ahau 
Haab Date               : 8 Cumku

With NLS support (see section NLS), you can specify a different language and get appropriate output:

Command: LANG=de mdate

German output:

Gregorianishe Datum     : 21-M@"arz-2000 (21/3/2000)
Julianische Tagzahl     : 2451625.0 
Lange Z@"ahle           : 12.19.07.01.00 
Tzolkin Datum           : 11 Ahau
Haab Datum              : 8 Cumku

Gregorian date input

Gregorian date input takes the following form:

`-d dd mm [-BC|+AD]yyyy'

Where dd, mm, and yyyy are numerical digits representing day, month and year respectively.

year can be BC or AD Gregorian, the optional - indicating which side of the imaginary Gregorian year 0. +AD can be omitted for all dates after Gregorian year 0.

Example (with program-parseable output) :

mdate -p -d 13 08 -3113

Output:

JDN:  584285.0 date:  13  08 -3113 00.00.00.00.00  04 Ahau    08 Cumku

Note that this is the earliest acceptable Gregorian date using the default correlation.

Long Count input

Long Count input takes the following form:

`-l nn nn nn nn nn'

Where nn may be one or more decimal digits, e.g. 01 ,10 or 1.

Example (with program-parseable output) :

mdate -p -l 00 00 00 00 00

Output:

JDN:  584285.0 date:  13  08 -3113 00.00.00.00.00  04 Ahau    08 Cumku

Note that this is the earliest acceptable Long Count using the default correlation.

Julian Day Number input

Julian Day Number (JDN) input takes the following form:

`-j nnnnnnnnn.0'

Where nnnnnnnnn.0 is any number of digits up to nine plus a decimal point and 0 representing a decimal number. JDN's greater than this will cause an overflow error, and negative numbers are not accepted by the program.

Example (with program-parseable output) :

mdate -j 584285.0

Output:

JDN:  584285.0 date:  13  08 -3113 00.00.00.00.00  04 Ahau    08 Cumku

Note that this is the earliest acceptable JDN using the default correlation.

Input Restrictions

The most obvious restriction is no input via either Tzolkin or Haab calendar dates, for the simple reason being that it is difficult, if not impossible to calculate when a specific combination of calendars occurred. It is possible to estimate dates that are near the date in question. This is because of the nature of the Mayan calendar system (see section Correlating Calendars).

Mdate tries to catch input errors either through mistyping a date format, or dates before the beginning of the JDN-Mayan correlation date.

The Mayan Calendar

The Mayan calendar is a combination of three calendars, the solar (Haab) and sacred (Tzolkin), and a more general day count (Long Count). The Maya used a vigesimal (base 20) number system, and based on their astronomical observations (particularly of Venus) and their religious beliefs, were attracted to particular mathematical properties of planetary cycles: 13, 20, 60, 260, 360 were very popular numbers.

The properties of these numbers led to a interestingly complex mathematical relationship between their calendars. For instance, the Tzolkin calendar's cycle is predictable because the numbers 20 and 13 are relatively prime (a fact very handy in other calculations).

All Mayan names in this guide are the standard nomeclature, although the newer Mayan standard for names is quickly overtaking it.

The Long Count

The Mayan Long Count is essentially a structured count of days between one epoch (reckoned in baktuns) and another. There are various subunits associated with the Long Count detailed below.

Long Count units

The basic units of the Long Count are:

• 1 kin = 1 day
• 1 unial = 20 kin (20 d)
• 1 tun = 18 uinal (360 d)
• 1 katun = 20 tun (7200 d)
• 1 baktun = 20 katun (144,000 d)

For example, today's date (23rd, March 2000) is 12.19.07.01.02 or 12 baktun, 19 katun, 7 tun, 1 uinal and 2 kin.

There are several larger units, of which the pictun (20 baktun or 2,880,000 days) is the only unit of major interest, since it forms the most important epoch of which this current baktun is the 20th and last. The end of this baktun (22nd December, 2012) ends this epoch, and according to the Maya, this world! It will have taken 7885 solar years to come to pass.

The Calendar Round

An important subunit of Mayan day counting is the Calendar Round, abbreviated CR. This refers to a cycle upon which the same combination of Haab and Tzolkin calendars on a particular date returns (actually the least common multiple of 365 x 260 days), every 18,980 days or about 52 solar years.

This cycle is important, because it helps to check calculations from the epoch (0.0.0.0.0 4 Ahau 8 Cumku) by each CR. It also is vital in any estimate of days elapsed between particular Haab/Tzolkin date combinations. Combined with accurate Long Count references, this is the best way to back-check particular subperiods in Mayan history without reference to other more ceremonial cycles.

The Haab Calendar

The Haab, or solar calendar, is made up of 18 months of 20 days each (360 days), and 5 "unlucky" days, called Uayeb. All dates in each month were numbered from 0 to 19, with days in Uayeb numbered 0 to 4.

The month names are:

The Tzolkin Calendar

The Tzolkin, or sacred calendar, consisted of 260 days made up of two cycles: a 13 day count and a 20 name count. Each day in the 260 day year is thus unique, as both counts are simultaneous. For example, after 13 Kan comes 1 Chicchan. This fact, combined with the Haab calendar guarantees that in any given year, only four particular dates are possible. This is very helpful in tracking particular years, using the Calendar Round.

The Tzolkin month names are:

Correlating Calendars

There is much academic argument about the correct correlation between the Gregorian and Mayan calendars. For years, the Goodman-Martinez-Thompson (G-M-T) correlation has been a standard, but the problems associated with it and evidence from surviving Mayan relics have diminished its stature.

I have seen programs supporting more than five correlations. The correlation used by default in Mdate is the "corrected" G-M-T from astronomical and Mayan records.

In essence, there are two problems: the Julian Day Number system itself, and what constitutes a valid Mayan date to be compared with.

The JDN system is known to have errors in its initial calculation, which puts some correlations out by as much as two or three days. The Mayan system itself, while incredibly accurate, does "lose time" over long periods. It is conjectured that the Maya themselves knew this and actually corrected their calendar based on their superb astronomical observations. Relics believed to confirm this have been found, and corrected G-M-T is one result.

Without neither attempting to reform the JDN system for the purposes of a Mayan calendar program, nor ignore what are valid Mayan records, the correlation used for Mdate is, I feel, the best compromise. The debate still rages on and G-M-T and corrected G-M-T are the two main camps.

corrected G-M-T is defined as JDN_CORRELATION 584285.0L, and standard G-M-T would be JDN_CORRELATION 584282.0L in Mdate's code, a difference of about three days. However, corrected G-M-T is accurate as far as the end of the epoch, 22nd December, 2012.

Compilation Options and Notes

Mdate uses the standard GNU autoconf system for producing and installing the program, and it is pretty straightforward.There are at present only three things you're likely to be concerned with when compiling Mdate:

Correlation

Mdate uses "corrected G-M-T" for synchronizing Gregorian and Mayan calendar dates.

If you really hate the Gregorian-Mayan correlation used by Mdate, you will have to redefine JDN_CORRELATION 584285.0L to a correlation you prefer in mdate.h. See section Correlating Calendars, for a discussion of correlations.

NLS

Mdate is intended to be used all over the world, and includes internationalization support. If your native language is English, this may not apply to you.

libmdate itself does not currently require NLS to compile: this eases options for both users and developers. This may need to change in the future.

Files

Apart from the optional NLS support, the command-line Mdate requires an installed version of libmdate, including the mdate.h header file.

Bugs

There will be bugs - please report any to:

Sean Dwyer ewe2@users.sourceforge.net

or to any of the Mdate Development Team at mdate.sourceforge.net. Please check this URL regularly as the site is still being updated. A bugs interface will soon be added for your convenience and prompt attention.

libmdate C API

This chapter/node has yet to be fully written. Work is being done to complete it. Mdate is being redeveloped as a useful library to aid porting to other architectures and interfaces. This section hopes to aid programmers interested in such work with their task.

API Overview

The Mdate API is not yet finalised: this is an ongoing project by the Mdate Development Team. What is here is a general description of the Mdate API up to version 0.0.3. Very likely, version 0.0.4 and beyond will be very different, and this section will evolve with it.

libmdate is basically a math-based calendar conversion library, allowing input, and by default using the OS time API to output the current date.

The crucial conversion factor (as in many other calendar-related utilities) is the Julian Day Number (JDN). libmdate uses a rounded JDN, omitting the standard astronomical addition to the decimal number, but retaining the JDN's decimal character.

In the following sections, values that are global defines are classed as a Define, other data types and variables use the standard macros for tex/texinfo files.

All functions, constants and definitions discussed below are defined in mdate.h. Internal functions, etc. are not discussed unless they affect implementation.

Portability Concerns

There are several system-dependent functions used by libmdate: most GNU-based system should have no trouble with them. We are particularly concerned to port to those systems lacking drem() and snprintf().

System Function: double drem (double x, double y)

drem() is a BSD-derived maths function, which is IEEE 754 and 854 specification compliant. In recent versions of AIX and HPUX, drem() has been replaced by remainder(). The GNU assembley implementation of drem uses an IEEE-specific instruction to return the modulus of a double-precision floating-point number regardless of sign, in contrast to the standard fmod() function. Its use in libmdate is to avoid side-effects of the calculation of Julian Day Numbers.

System Function: size_t strftime (char *string, size_t max, const char *format, const struct tm *tm )

strftime() formats the data from struct tm and puts it in the array *string. As this function is generally ANSI C compliant, many systems will already have it.

System Function: int snprintf (char *string, size_t n, const char *format, ... )

This is a GNU-specific function that takes a variable number of arguments and copies them to *string according to *format up to at least n characters. n for libmdate is at least 256 characters.

Definitions and Constants

Define: JDN_CORRELATION {long integer}

Defines the default correlation for all date conversions in Mdate. JDN_CORRELATION, although defined as a long integer, is really treated as a double in all conversions.

typedef double: julian_date

To be certain that julian_date is always treated as a double.

typedef enum: false, true BOOL

A necessary typedef. The BOOL typedef enables certain functions to return a boolean value in a way that is not system-specific. Although recent C/C++ compilers support the bool data type, it is unwise to expect it by default.

The basic data types used by libmdate are integrated structures from which functions get data and to which they return values.

Structure: struct long_count {

int bak, int kat, int tun, int uin, int kin; }

The Long Count data type.

Structure: struct greg_date {

int day, int month, int year; }

The Gregorian calendar data type.

Structure: struct haab_date {

int month, int day; }

The Haab calendar data type.

Structure: struct tzolkin_date {

int month, int day; }

The Tzolkin Calendar data type.

Conversion Routines

These are the currently implemented public functions:

Function: BOOL jdate_from_double_jd (double from, struct julian_date *to)

Validity tests a JDN and ensures it remains a double-precision number.

Function: void jdate_to_str (struct julian_date from, char *to)

Copies the current value of struct julian_date to a string buffer.

Function: BOOL jdate_from_greg_date (struct greg_date from, struct julian_date *to)

Calculates a JDN from a Gregorian date.

Function: BOOL jdate_from_long_count (struct long_count from, struct julian_date *to)

Calculates the JDN from a Long Count.

Function: BOOL jdate_from_tm (struct tm from, struct julian_date *to)

Calculates the JDN from the current date in struct tm.

Function: BOOL greg_date_from_jdate (struct julian_date from, struct greg_date *to)

Calculates the Gregorian Date based on a JDN.

Function: void greg_date_to_str (struct greg_date from, char *to)

Copies the current variables of struct greg_date to a string buffer.

Function: BOOL haab_date_from_jdate (struct julian_date from, struct haab_date *to)

Calculates the Haab date from a JDN.

Function: BOOL haab_month_to_str (int from, char *to)

Copies the current string value of the Haab month to a string buffer.

Function: BOOL haab_date_to_str (struct haab_date from, char *to)

Copies the current variables of struct haab_date to a string buffer.

Function: BOOL tzolkin_month_to_str (int from, char *to)

Copies the current string value of the Tzolkin month to a string buffer.

Function: BOOL tzolkin_date_to_str (struct tzolkin_date

from, char *to) Copies the current variables of struct tzolkin_date to a string buffer.

Function: BOOL tzolkin_date_from_jdate (struct julian_date from, struct tzolkin_date *to)

Calculates the current Tzolkin date from the JDN in struct julian_date.

Function: void long_count_to_str (struct long_count from, char *to)

Copies the current variables of struct long_count to a string buffer.

Function: BOOL long_count_from_jdate (struct julian_date from, struct long_count *to)

Calculates the current Long Count from the JDN in struct julian_date.

Function: BOOL is_valid_jdate (double jul)

Bounds checks JDN's.

Function: BOOL is_valid_greg_date (struct greg_date date)

Bounds checks Gregorian dates for validity.

There are a number of internal functions:

Function: static double my_mod (double x, double y)

Internal function that performs accurate modulus on signed double-precision floating-point numbers.

Function: static int gregoran_leap_year (int g_date)

Tests a given Gregorian date for leap years.

Finally, functions included in the API but not yet implemented:

BOOL jdate_from_time_t (struct time_t from, struct julian_date *to)

BOOL is_valid_struct_tm (struct tm date)

BOOL is_valid_long_count (struct long_count date)

BOOL tm_from_jdate (struct julian_date from, struct tm *to)

BOOL time_t_from_jdate (struct julian_date from, struct time_t *to)

Interface Routines

Interfaces to libmdate must satisfy the API of the interface as well as that of libmdate. Using the current command-line interface as an example console.c , we can divide the basic interface tasks as follows:

- Test input

libmdate provides functions with simple boolean return values to test input. In some cases (e.g. testing whether the input Gregorian date is valid), you must provide your own error messages.

- Format output

libmdate provides standard output formats that you can retrieve from string buffers. See section Date-entry Options, for examples of these formats.

- Provide help

Functions you must also provide are functions to handle version information and help.

Event-driven interfaces are naturally different to command-line interfaces, but there are still some guidelines both can follow:

- Always provide the current date.

tkmdate (which provides an event-driven interface to mdate) initializes with the current date in Mayan calendar format. This could be very attractive in a GNOME or KDE panel for instance. It isn't necessary to output the JDN in this case unless you wish to, but you should allow for users wishing to use JDN output as a guide.

- Use "mdate" in the program name.

This is only a suggestion, but calling your interface "Gmayan" for instance, would be confusing for users and developers.

The Future

What is the future of the libmdate API? The current goals are documentation, simplification and generalization, to make a useful library possible.

Generalisation will undoubtedly necessitate porting of the drem function to other architectures besides that of the x86 processors. Its dependence on an IEEE-specific x86 instruction will make this difficult. An alternative C (or assembler) function to replace this dependency is sought for those architectures unable to use such instructions.

Protecting string arrays because of the use of internationalization support is also vital. When possible, moving towards use of the wchar_t data type to ease translation may help this.

Simplification makes these tasks easier (because the code becomes more modular), and enables better debugging support. Mdate is not meant to be an all-round calendar conversion program, but it makes porting and interfacing projects more feasible.

Finally, documentation improves the chances of libmdate getting wide acceptance among those who need such a library. It shouldn't be relegated to the status of an add-on to emacs, or an interesting toy, but something of general use to those interested in the Mayan calendar.

Copying

GNU Free Documentation License.

		GNU Free Documentation License
		   Version 1.1, March 2000

 Copyright (C) 2000  Free Software Foundation, Inc.
     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other
written document "free" in the sense of freedom: to assure everyone
the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially.  Secondarily,
this License preserves for the author and publisher a way to get
credit for their work, while not being considered responsible for
modifications made by others.

This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense.  It
complements the GNU General Public License, which is a copyleft
license designed for free software.

We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does.  But this License is not limited to software manuals;
it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book.  We recommend this License
principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be distributed
under the terms of this License.  The "Document", below, refers to any
such manual or work.  Any member of the public is a licensee, and is
addressed as "you".

A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly
within that overall subject.  (For example, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any
mathematics.)  The relationship could be a matter of historical
connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding
them.

The "Invariant Sections" are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License.

A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input
to text formatters.  A copy made in an otherwise Transparent file
format whose markup has been designed to thwart or discourage
subsequent modification by readers is not Transparent.  A copy that is
not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML
or XML using a publicly available DTD, and standard-conforming simple
HTML designed for human modification.  Opaque formats include
PostScript, PDF, proprietary formats that can be read and edited only
by proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the
machine-generated HTML produced by some word processors for output
purposes only.

The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page.  For works in
formats which do not have any title page as such, "Title Page" means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License.  You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute.  However, you may accept
compensation in exchange for copies.  If you distribute a large enough
number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and
you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies of the Document numbering more than 100,
and the Document's license notice requires Cover Texts, you must enclose
the copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover.  Both covers must also clearly and legibly identify
you as the publisher of these copies.  The front cover must present
the full title with all words of the title equally prominent and
visible.  You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.

If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a publicly-accessible computer-network location containing a complete
Transparent copy of the Document, free of added material, which the
general network-using public has access to download anonymously at no
charge using public-standard network protocols.  If you use the latter
option, you must take reasonably prudent steps, when you begin
distribution of Opaque copies in quantity, to ensure that this
Transparent copy will remain thus accessible at the stated location
until at least one year after the last time you distribute an Opaque
copy (directly or through your agents or retailers) of that edition to
the public.

It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give
them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it.  In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct
   from that of the Document, and from those of previous versions
   (which should, if there were any, be listed in the History section
   of the Document).  You may use the same title as a previous version
   if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
   responsible for authorship of the modifications in the Modified
   Version, together with at least five of the principal authors of the
   Document (all of its principal authors, if it has less than five).
C. State on the Title page the name of the publisher of the
   Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
   adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice
   giving the public permission to use the Modified Version under the
   terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections
   and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled "History", and its title, and add to
   it an item stating at least the title, year, new authors, and
   publisher of the Modified Version as given on the Title Page.  If
   there is no section entitled "History" in the Document, create one
   stating the title, year, authors, and publisher of the Document as
   given on its Title Page, then add an item describing the Modified
   Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for
   public access to a Transparent copy of the Document, and likewise
   the network locations given in the Document for previous versions
   it was based on.  These may be placed in the "History" section.
   You may omit a network location for a work that was published at
   least four years before the Document itself, or if the original
   publisher of the version it refers to gives permission.
K. In any section entitled "Acknowledgements" or "Dedications",
   preserve the section's title, and preserve in the section all the
   substance and tone of each of the contributor acknowledgements
   and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document,
   unaltered in their text and in their titles.  Section numbers
   or the equivalent are not considered part of the section titles.
M. Delete any section entitled "Endorsements".  Such a section
   may not be included in the Modified Version.
N. Do not retitle any existing section as "Endorsements"
   or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant.  To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.

You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version.  Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity.  If the Document already
includes a cover text for the same cover, previously added by you or
by arrangement made by the same entity you are acting on behalf of,
you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice.

The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy.  If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled "History"
in the various original documents, forming one section entitled
"History"; likewise combine any sections entitled "Acknowledgements",
and any sections entitled "Dedications".  You must delete all sections
entitled "Endorsements."

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all
other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, does not as a whole count as a Modified Version
of the Document, provided no compilation copyright is claimed for the
compilation.  Such a compilation is called an "aggregate", and this
License does not apply to the other self-contained works thus compiled
with the Document, on account of their being thus compiled, if they
are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one quarter
of the entire aggregate, the Document's Cover Texts may be placed on
covers that surround only the Document within the aggregate.
Otherwise they must appear on covers around the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections.  You may include a
translation of this License provided that you also include the
original English version of this License.  In case of a disagreement
between the translation and the original English version of this
License, the original English version will prevail.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License.  Any other attempt to
copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License.  However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such
parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions
of the GNU Free Documentation License from time to time.  Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
http:///www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation.  If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.

ADDENDUM: How to use this License for your documents

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and
license notices just after the title page:

      Copyright (c)  YEAR  YOUR NAME.
      Permission is granted to copy, distribute and/or modify this document
      under the terms of the GNU Free Documentation License, Version 1.1
      or any later version published by the Free Software Foundation;
      with the Invariant Sections being LIST THEIR TITLES, with the
      Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
      A copy of the license is included in the section entitled "GNU
      Free Documentation License".

If you have no Invariant Sections, write "with no Invariant Sections"
instead of saying which ones are invariant.  If you have no
Front-Cover Texts, write "no Front-Cover Texts" instead of
"Front-Cover Texts being LIST"; likewise for Back-Cover Texts.

If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License,
to permit their use in free software.

Index

-

a

b

c

d

f

g

h

i

j

l

m

n

o

p

s

t

u

v

w

This document was generated on 3 June 2000 using the texi2html translator version 1.54.