INQUA - COMMISSION FOR THE STUDY OF THE HOLOCENE Working Group on Data-Handling Methods Newsletter 7, January, 1992 NOTE FROM THE COORDINATOR The Newsletter has been fun to assemble this time. Keith Bennett describes how PostScript can be used to send both text and diagrams by e-mail, and his two pages were sent from England and included in the newsletter essentially as they came off our printer. I am very much in favor of his suggestions for many purposes; however, like FAX, the receiver gets the material quickly, but--unlike digital data files or generic text--finds further processing difficult. I have asked Jacques-Louis de Beaulieu, Joel Guiot, and Rachid Cheddadi to describe the European Pollen Database in some detail, and their material helps us see Human factors that come to play when people's data are to be shared. Owen K. Davis has a questionnaire on how we all work with data. He is doing a chapter on this topic, and I hope all the readers will xerox the response page, fill it out, and send it to him. Pierre A. Zippi has obliged me by sending material about his programs designed for the Macintosh. A number of those in my department use his pro- grams and like them. Bent Odgaard provides some very good tips for working efficiently with TILIAłGRAPH. Dr. Triage is back for a second stint, and I describe DEP-AGE for getting sedimentation rates. After Newsletter #6 was mailed last summer, I sent a statement to Brigitta Ammann to recover a couple of hundred dollars for paper, printing, and postage. A few weeks later I received a phone call from the New York offices of Credit Suisse. The voice on the phone said: "Mr. Maher, yesterday we mailed you a check for $12,837.68." I gasped involuntarily, but I quickly recovered. Undoubtedly the INQUA Holocene Commission was merely expressing its complete satisfaction with the Newsletter. The voice went on however; "We have stopped the check and issued a new one for the correct amount. Please return the stopped check to our office." Well, it was a great feeling for the moment it lasted. I ask the readers of the Newsletter to send me information on any of the data-handling techniques that you have used which could be helpful to others. Please check your regular and e-mail addresses for accuracy. Send any corrections or suggestions to: Louis J. Maher, Jr. Department of Geology & Geophysics University of Wisconsin 1215 W. Dayton Street Madison, WI 53706 USA Phone: (608) 262-9595 FAX: (608) 262-0693 E-mail: maher@geology.wisc.edu THE EUROPEAN POLLEN DATABASE Jacques-Louis de Beaulieu Joel Guiot Labo. Botanique Historique Facult‚ de St. J‚rome 13397 Marseille CEDEX 13 France Rachid Cheddadi Banque Europeenne de donnees polliniques Centre Universitaire Espace Van Gogh 13637 Arles France A European Pollen Database (EPD) is now being developed to provide for all palynologists a permanent archive of the basic data generated by pollen analysts in Europe, a tool for further research on palaeoecological and biogeographical problems at a variety of temporal and spatial scales, and a primary data-source for furthering our understanding of past environmental history at a time when research on Global Change is becoming increasingly important. The European Pollen Database project is centralized in Arles, France. Its personnel consist of a post-doctoral scientist (R. Cheddadi) working closely with Joel Guiot and Jacques-Louis de Beaulieu. The EPD has an Executive Committee responsible for overseeing the development of the project and for finding further financial support for the project. There is also an Advisory Board responsible for protocols, assisting with pollen-taxonomic and related problems, and arbitration in any disputes between contributors, users, or coordinators. The composition of the Executive Committee is currently Brigitta Ammann, Jacques- [*p.1 / p.2*] Louis de Beaulieu and Brian Huntley. The Advisory Board consists of Karl-Ernst Behre (Wilhelmshaven), John Birks (Bergen), Elizaveta Bozilova (Sofia), Maria Follieri (Rome), Marie-Jose Gaillard-Lemdahl, George Jacobson Jr., Roel Janssen (Utrecht), Meilute Kabailiene (Vilnius), Magdalena Ralska-Jasiewiczowa (Cracow). The Advisory Board have resolved that data compilation shall give priority to sites that formed part of the IGCP 158B sub-project. It was agreed that high data quality must be guaranteed, and that high taxonomic standards and sound radiocarbon chronologies were essential. The database must contain the data in their entirety for all sites contributed. The data to be compiled and stored will extend far beyond the pollen counts. Precise details of the site location, the present vegetation surrounding the site, the sediment lithology, the chronology, all bibliographic details relating to published accounts of the site, and the name(s) and address(es) of the worker(s) who sampled and analyzed the site will be included in the database. The database coordinators must cooperate closely with the contributors, with regional advisors and groups and with the Advisory Board in order to resolve pollen-taxonomic questions. Appropriate protocols are in progress for these purposes. The protocols for the database were discussed and agreed by the Advisory Board at its meeting of the 22nd September 1990 at Wilhelmshaven. In the event that it becomes necessary to modify them in the future, all database contributors and users will be notified and the changes will be published in a Newsletter. At present there are three directly related database subprojects and one indirectly related database project. The three subprojects are concerned with specific geographical areas or temporal aspects and were, at their outset, designed to be integral components of the EPD. They consist of: 1. Eastern Mediterranean database coordinated by Sytze Bottema (Groningen) as part of the EPOCH project on Global climate change of the last 30,000 years. 2. 9000 - 15,000 B.P. ("late-glacial") of Europe coordinated by Annabel Gear and Brian Huntley (Durham) as part of their project on European Palaeo- climate during the last deglaciation. 3. Last interglacial of Europe coordinated by Mike Field, Phil Gibbard (Cambridge) and Brian Huntley, as part of their project on Palaeoclimate and vegetation development during the last interglacial in Europe. The indirectly related project is the Alpine database. This is part of a larger project specifically focussed on long-term vegetational dynamics in the Alps and immediate surroundings coordinated by Brigitta Ammann (Bern). It was not originally designed to be an integral component of the EPD. However it is attempting to achieve the maximum possible compatibility with the EPD in terms of database design, software, etc. The initiation of other regional or thematical database groups are in progress. Following discussion, it was decided to use the relational database package PARADOX (version 3.5) to build the database. This software is widely avail- able and runs on IBM PC-compatible computers under DOS; it is also being adopted by the North American Pollen Database, thus application software developments can be shared. The EPD closely collaborates with the NOAA NGDC American pollen database project coordinated by Eric Grimm and John Keltner, particularly in connections with computer software development. In January 1991 the first Newsletter including a questionnaire has been sent to European Quaternary palynologists. To-date 90 respondents have offered data from different parts of Europe and already 440 sites situated in more than 20 countries have been offered. In order to compile and record all of this information a series of data recording sheets was prepared and sent to contributors. The teams involved in the technical management of the database and in the compilation of data (Arles, Cambridge, Durham and Springfield) have spent much of the last six months solving software prob- [*p.2 / p.3*] lems and laying foundations for the data compilation that is now underway. The PARADOX table structure has been modified in several respects in the light of experience and to facilitate the preparation of scripts that will allow the data in the tables to be manipulated and/or queried more efficiently. Scripts to prepare the empty tables have been written and the tables are now in use as data compilation has gotten underway. The EPD is now ready to welcome in Arles all scientists who wish to be trained in the software and programs used by the database. The first data release is estimated to be available in about one year from now following the EPD protocol. Support was obtained from the European Science Foundation that will enable the Executive Committee to organize a workshop meeting on "Computer management of pollen data in relation to human impact and climatic changes" that will take place in Arles in the spring of 1992. These funds will enable some younger scientists from central and eastern Europe, as well as the Advisory Board, to attend the meeting and will afford the opportunity for some of these workers to extend their stay in Arles by a few days to be trained in the use of the E.P.D. software available at that time. The Advisory Board will meet during the workshop to deal with EPD business. A particular matter that requires attention is that of the synonymy and hierarchic relations of the pollen taxa listed to-date. It will probably prove necessary to organize working group meetings to deal with some aspects of this problem. The funding obtained from the EC allowed launching the database for the first two years. The Advisory Board has now to insure the survival of the database structure after that period. Protocols for the European Pollen Database 22nd September 1990 - Wilhelmshaven A. Data 1. Data must consist of the original counts, not percentages or digitized data. 2. Database must contain the original taxonomic identifications, with exceptions of exact nomenclatural synonymy. Taxa will not be lumped into higher taxonomic groups in the database. 3. Data will be classified as unrestricted or restricted. All data will be available in the database. In other words, the central database will distribute all data, restricted and unrestricted. Thus, restricted data can be viewed by a user, but cannot be used except as provided below. 4. Unrestricted data are available for all uses. 5. Restricted data may be used only by permission of the data originator. Appropriate and ethical use of restricted data is the responsibility of the data user. B. Contributors 1. Can declare data unrestricted or restricted. 2. Can ask to verify that data in the database are correct. As a matter of general policy, the central database should routinely return to the data originator a hardcopy printout of the data as they are entered in the database for optional verification by the originator. 3. May use any unrestricted data. 4. Can obtain copies of application software and the database itself for use on his/her own computer. 5. Should receive a periodic newsletter or report concerning the database. 6. Can ask at any time that his/her data be withdrawn from the database or that their status (unrestricted or restricted) be changed. 7. In the case of a dispute regarding inappropriate use of restricted data, the Advisory Board will serve as arbitrator. C. Users 1. Must ask permission from the data originator for use of restricted data. 2. Should, as a matter of courtesy, inform data originators of the uses being made of their data. [*p.3 / p.4*] 3. If the contributor wishes, should show the contributor results of analyses and manuscripts for publication for critical comment. 4. Should cite, in any publication using data from the database, the contributors' original publications describing their data. 5. Should send contributors reprints of publications that use their data. 6. Should acknowledge contributors for use of unpublished data and for any advice they may have provided. 7. No user can pass data on to another party. All users must obtain data from the central database. 8. Normal ethics apply to co-authorship of publications. The contributor should be invited to be a co-author if a user makes significant use of a single contributor's data, or a single contributor's data comprise a substantial portion of a larger dataset analyzed, or a contributor makes a significant contribution to the analysis of the data or to the interpretation of the results. This guideline applies to unrestricted as well as to restricted data. 9. The data are available only to non-profit-making organizations and for research. Profit-making organizations may use the data, even for legitimate uses, only with the written consent of the Advisory Board, who will determine or negotiate the payment of any fee required. D. Executive Committee and Database Coordinators 1. Should prepare a periodic newsletter or report about every six months for contributors, users, the Advisory Board, etc. 2. Must follow the same protocols that apply to all other users concerning the use of data. 3. Must closely cooperate with the data originator and/or relevant Advisory Board member(s), regional correspondents or taxonomic advisors when making taxonomic decisions. 4. Should assemble a mailing list of Quaternary palynologists in Europe and others associated with European data, and should inform them of the oppor- tunity to contribute to and participate in the database development. In addition, should announce the development of the database in appropriate newsletters and publications. 5. Should incorporate all data into the database, subject to certain minimum requirements, without assignment of quality. 6. Should organize workshops on matters related to the database and should work to facilitate acquisitions of hardware and software by laboratories not having access to these. 7. Should send the protocols to all potential contributors and users. In addition to abiding by these protocols, the database compilers and coordinators have agreed that they will regard all data that are added to the database as restricted (see above) until they appear in a version of the database that has been released to other users. BORLAND SOFTWARE L. J. Maher A Borland International representative recently called me to offer an upgrade to QUATTRO PRO which I had already purchased. During the conversation I mentioned that PARADOX 3.5 was being used in both the European and North American Pollen Databases, and I asked if Borland would be able to offer the program at reduced price to educational institutions. He said he would discuss possible educational discounts for PARADOX if interested parties wrote to him at the following address: Customer Service ATTN: Dennis Kean Borland International P.O. Box 660001 Scotts Valley, CA 59066 USA (Note: In database reviews in trade journals, PARADOX is said to list for $795 US. However prices from mail-order firms currently range from $500 to as low as $475. Should you write to Borland and be offered a discount, keep these street prices in mind.) [*p.4 / p.5*] SPEEDING UP SCREEN PLOTTING IN TILIAłGRAPH Bent Odgaard Geological Survey of Denmark Thoravej 8 DK-2400 Copenhagen NV Denmark TiliałGraph offers very versatile plotting facilities which will meet most of the wishes of even critical users. The wide range of options often demand many step-wise menu changes and repeated "Make diagram" and "View diagram." For those of us who do not have access to the newest high-speed 486 computers with rapid screen cards and speedy hard disks, but merely to a 286- or 386SX- based "antiquity," the repeated plotting of large diagrams on screen can be somewhat patience-challenging. However, do not despair; there are ways of making this plotting faster even on "antiquities." During some months of intensive use of Tilia and TiliałGraph I have found the following tricks to work well on my PC, and I communicate them in the hope that others might find them useful. 1. If you have more than 1 Mb of RAM on your system use some or all of this for a disk-caching program like DOS's SMARTDRV.SYS or NORTON's NCache-S. I have a total of 2 Mb RAM and use 960 Kb for SMARTDRV.SYS, which significantly speeds up the plotting of large diagrams. Extra RAM-cards are now inexpensive. 2. Use the VGA 2-colour driver delivered with TiliałGraph instead of the VGA 16 colour driver. This speeds up plotting slightly and makes no other difference for those of us who only view the diagram in two colors. (The Tilia logo will, admittedly, look less sophisticated.) 3. Some makes of screen cards are delivered with a small TSR-program that uses RAM for video BIOS operations and hence speeds up writing to the screen. My Genoa card was delivered with a RAMBIOS.SYS which, when installed in the CONFIG.SYS-file, gives somewhat quicker plotting on screen. As a TSR-program it eats up about 32 Kb of the precious RAM available for programs, but using DOS 5.0 I still have plenty (560 Kb) for TiliałGraph to run. 4. Since TiliałGraph is a disk-intensive program, optimizing your hard disk by e.g. NORTON's SPEEDISK, will increase performance also. 5. Finally two reminders: Only use the high resolution Leroy-font for the final plotting, and remember that you do not have to wait for the entire plot to have finished on the screen before you zoom in by pressing the "+" key. COMPUTER CLASS AFTER AIX PALYNOLOGY CONGRESS L. J. Maher, Jr. A number of you will be attending the 8th International Palynology Congress that meets from September 6 - 12, 1992, in Aix-en-Provence, France. It seemed a good opportunity to offer a short course on computer data-handling as well as some training in the use of TILIAłGRAPH, PALYPLOT, and other display programs. Scheduling conflicts makes it impossible to run such a course during the actual conference, but Raymonde Bonnefille has offered the use of her laboratory (Laboratoire de Geologie du Quaternaire, Centre Universitaire de Luminy, Marseille, France) and its IBM compatible computers early in the week following the conference (Monday, Tuesday, and Wednesday, September 14 - 16, 1992). Joel Guiot, Annie Vincens, and Lou Maher are in change of planning the workshop, and Eric Grimm has agreed to be present to instruct in the use of TILIA and TILIAłGRAPH. The class will be free, and those attending can arrange for lodging on the Luminy campus "for about 150 FF per day." The workshop committee will be handling the registration details. Several of you have expressed interest in this course. Others who want to attend or know someone who should take the course, please get in touch with Lou Maher as soon as possible at the address listed on the front page of this Newsletter. The number of available computers will limit the enrollment to one or two dozen. It should be a good time, and there is still some room. If you have a laptop with >= EGA screen, bring it along. [*p.5 / p.6*] USE OF PostScript TO INCREASE PORTABILITY OF POLLEN DIAGRAMS K.D. Bennett Sub-department of Quaternary Research University of Cambridge Botany School Downing Street Cambridge CB2 3EA United Kingdom kdb2@uk.ac.cam.phx The plotting of pollen diagrams has always been a highly individual process, dependent on locally available hardware and software. Because different printers and plotters run from different sets of control sequences, it has not been possible to transport the information needed to plot a pollen diagram except as the data itself or as a finished, camera-ready diagram. In principle, two users with identical hardware and software could exchange a plotter file (as described by Lou Maher in Newsletter 6, July 1991), but in practice this is rarely done. The PostScript language provides a way to describe any piece of graphics or text in an ASCII file which can be read and interpreted on many printers (especially, but not exclusively, laserprinters). Software packages now often include a PostScript driver which can either send output directly to the printer/plotter, or generate an ASCII file with the commands to generate the work on any output device with a PostScript interpreter. Since a driver is available in many packages, and the interpreter is available in many output devices, the ASCII file provides a useful way to link the two without both being present at the same site. For example, I do not have Generic CADD5, so I cannot print a copy of Lou's Russian sampler diagram from his .DWG file. But if the plotter file had been written in PostScript, I would be able to produce hardcopy on our laserprinter. As an ASCII file, the PostScript file can be easily moved by e-mail, using file compression, as described by Lou, where necessary. PostScript is probably most readily available in the Apple LaserWriter printers, but can be added to many other printers by purchase of an additional card. The Apple LaserWriter is an excellent laserprinter, and it can be connected to PC-compatibles through a COM port, but it may be necessary to tinker with the wiring to overcome the incompatibility of Apple and IBM (see, for example, Glover 1989). This note was written using Wordstar, and printed to an ASCII file using the PostScript driver provided. The pollen diagram was generated from an ASCII file produced from the dataset by a QuickBASIC program. Both files were sent to Lou as e-mail, and were printed by him using his printer. Lou does not have the program used to produce the pollen diagram, and would not be able to generate the diagram himself without the data set, which he would need to convert to a format required by his programs. Sending the copy like this is straightforward for me, sparing me the trouble of packing camera- ready copy in a form to survive postal services, while enabling Lou to produce the copy with no extra editing, and on his own printer uniformly with other copy. He does not need to know what software I used to produce the files, and I need no information about his software or hardware, other than this his output device has a PostScript interpreter. The PostScript language is a 'simple interpretative programming language' (Adobe Systems Incorporated 1990), which describes the appearance of a page, whether text, graphics, or both. Adobe own the copyright in the operators and specification of PostScript, but allow anyone to use them, under certain conditions. A typical file will have a header, such as %!PS-Adobe-2.0, definition of sundry parameters for the page (e.g. font, character size), and definition of operators (to reduce repetition in the body of the page). %%, followed by a keyword, introduces a standard set of 'document structuring conventions'. Operands precede their operators, so (ABC) show prints 'ABC' at the current location. showpage prints the current page and prepares for the next. For graphics, 20 40 lineto is one segment of a 'path', from '0 0' to '20 40' in the current co-ordinates. Text and graphics alike can be moved around on the page, rotated, and scaled. PostScript files are ASCII, so they can be edited using an appropriate editor (e.g. 'EDIT' in DOS 5, or 'non-document' mode of Wordstar), and I do this with text files to include special characters, but there is not too much that can be done with this kind of fiddling. More significant is the possibility of writing PostScript drivers in any programming language, and thus producing output from almost any software that can be printed on any output device with a PostScript interpreter. Use of PostScript thus has considerable potential for improving the ready portability of pollen diagrams, whether for publication or as part of information exchange. Adobe Systems Incorporated 1990. PostScript Language Reference Manual. Addison-Wesley Publishing Company, Reading, Massachusetts, 764 pp. Glover, G. 1989. Running PostScript from MS-DOS. Windcrest Books, 209 pp. [*p.6 / p.7*] PostScript figure of Dalican Water, Lunnasting, Shetland not reproduced here [*p.7 / p.8*] SEEING LAPTOP CURSORS L. J. Maher PC laptop computers are now close rivals of the desktop variety, and they can process a lot of data. Although they may have large memories, fixed drives, and VGA screens, the screen is still likely to be black and white, and the cursor may be hard to find. Here is a handy utility for making the cursor a large square that is hard to miss. The following script file is based on a listing that appeared in PC/Computing, v. 4, n. 7, p. 204 (July 1991). Use a wordprocessor or editor to produce the following text file exactly, including the square brackets; leave the 14th line completely blank as shown below: a 100 mov bx,0085 mov si,bx mov bx, 0040 mov es,bx es: mov ax,[si] sub ax,0001 mov cx,ax mov ah,01 int 10 mov ax,4c00 int 21 r cx 1b n bigcur.com w q Save the file as BIGCUR.SCR in the default directory as an ASCII text file. Then using DEBUG.EXE that comes with DOS, type: DEBUG < BIGCUR.SCR BIGCUR.COM, a 27-byte file should now be found in your directory. Copy it to a directory in your computer's normal search path. Typing this file's name will make your cursor big. When you no longer need it, type: 'mode co80' to restore your normal cursor. You can include the word BIGCUR in your laptop's AUTOEXEC.BAT file to have it load automatically. NEW BOOKSHELF 4 H.J.B. Birks The following recently published books may be of interest to readers of this Newsletter. R.S. Bradley (ed.) (no date) Global changes of the past. UCAR/Office for Interdisciplinary Earth Studies, Boulder. 514 pp. Paperback. C.J. Burrows 1990 Processes of vegetation change. Unwin Hyman, London. 551 pp. Paperback. D. Collett 1991 Modelling binary data. Chapman & Hall, London. 369 pp. Paperback. H.R. Delcourt & P.A. Delcourt 1991 Quaternary ecology. A paleoecological perspective. Chapman and Hall, London. 242 pp. Paperback. E.S. Edgington 1987 Randomization tests (Second edition). Marcel Dekker, New York. 341 pp. J. Guiot 1990 Methods and programs of statistics for paleoclimatology and paleoecology. INSU Quantification des Changements Climatiques: Methodes et Programmes. Monographie 1, 253 pp. (with IBM PC diskette). Paperback. R. Haining 1990 Spatial data analysis in the social and environmental sciences. Cambridge University Press, Cambridge. 409 pp. P.J.A. Howard 1991 An introduction to environmental pattern analysis. Parthenon Publishing, Carnforth. 254 pp. [*p.8 / p.9*] L.J. Hubert 1987 Assignment methods in combinatorial data analysis. Marcel Dekker, New York. 326 pp. J. Kolasa & S.T.A. Pickett (eds.) 1991 Ecological heterogeneity. Springer Verlag, New York. 332 pp. A.M. Mannion, 1991 Global environmental change. Longman, London. 404 pp. Paperback. J. Neter, W. Wasserman, & M.H. Kutner 1990. Applied linear statistical models (Third edition). Irwin, Homewood. 1181 pp. R.A. Reyment 1991 Multidimensional palaeobiology. Pergamon Press, Oxford. 377 pp. + 39 pp. Paperback. R.H. Shumway 1988 Applied statistical time series analysis. Prentice Hall, New Jersey. 278 pp. (with IBM PC diskette). M.G. Turner & R.H. Gardner (eds.) 1990. Quantitative methods in landscape ecology. The analysis and interpretation of landscape heterogeneity. Springer Verlag, New York. 536 pp. W.W.S. Wei 1990 Time series analysis - univariate and multivariate methods. Addison - Wesley, Redwood City, California. 478 pp. O. Wildi & L. Orloci 1990 Numerical exploration of community patterns. SPB Academic Publishing, The Hague 124 pp. Paperback. R.L. Wyman (ed.) 1991 Global climate change and life on earth. Routledge, Chapman and Hall, New York. 282 pp. Paperback. A QUESTIONNAIRE ON DATA-HANDLING Owen K. Davis Department of Geosciences University of Arizona Tucson, AZ 85721 How do you store your data? Do you still tally each pollen grain (or diatom, whatever) on piece of paper next to the microscope, store the count sheets in an envelope, and plot the diagrams with pen and ink? Most of us are somewhere between that extreme and an ideal of computerized automation. In evolving toward that utopia, we each have solved the problem of data storage in different ways. Lou Maher tells a story about an early attempt to standardize pollen counting. It takes place in Cambridge, England, in 1962. British Telephone had some surplus electric counters once used to charge customers for phone calls. Three palynologists working in the Cambridge lab decided to use parts from the electronic devices to make automatic pollen counters. Each person designed their own counter, and the results were quite different. One looked like a flute, another like a piano keyboard, and Lou's looked like a calculator. Its buttons were Legos, with safety-pins for return springs. Lou observes that this taught him that it is human nature to do things differently. I reached the same conclusion when I translated to my own data format (.PAK) from those used by John Birks (.BRX) and Lou Maher (.MHR). I still have the PASCAL source code for the program, which produced files that permitted me to plot, analyze, and compare one of my sites to theirs. Recently, I faced the problem again when I used John Birks' WACALIB program, which utilizes the "Cambridge Condensed Format." This is a variation of the format used by Ed Cushing's POLDATA, a mainframe monster I cut my teeth on while training to become a member of the Minnesota Mafia. Eric Grimm has faced the same problem. His "TILIA" reads 8 different formats: "Tilia, Minnesota, Cambridge, Marseille, Brown, Wisconsin, Matrix, and Lotus." I'd never heard of the Marseille format before, and I don't know if Cambridge is the ".BRX" or the condensed format. [*p.9 / p.10*] If you make it to the end of this article, you'll discover that my goal is to assess the magnitude of the data-conversion problem, in preparation for offering a solution. I'd like to know how you store your pollen (and other paleontological) data. Those who read this newsletter probably store their data in files on personal computers. I suspect that the formats fit into one of three general types described by Gajewski (1988, Newsletter 1, p.2-4.). The ATTRIBUTE format consists of stratigraphic series of samples (levels) listed by variable (pollen type). The counts may be in one column (.PAK), or may be in rows separated by spaces or commas (.BRX and .MHR). Variable names (pollen types) may begin each series (.PAK) or be grouped at the beginning or end of the file. The descriptors (site name, location, number of samples, and number of types) may be at the beginning, or--as you might guess--at the end of the file. The MATRIX format is smaller and simpler, and is used by most statistical packages. The data are in rows of types by columns of samples. The variable names, samples labels, and descriptors are not included - an inconvenient, and potentially disastrous (should they be lost) situation. The CONDENSED format is efficient for large data sets. Each sample is stored sequentially, and each (non-zero) pollen type is recorded as a name code- number pair. Depending on how many zeros there are, this format can be a real space saver. For data on aquatic organisms there are lots of zeros. Most taxa are abundant in a few samples, but are missing in the rest. Upland pollen data include many rare types that are present in only a few samples. The prime directive for the INQUA Data-handling Committee is to assist the exchange of data. In my opinion, this would be greatly facilitated by accepting one format that would be used in data exchange among committee members. Programming the various diagram-drafting and numerical analysis programs would be much simpler if data were stored in, or easily-translated to this format. Surely, this should be an ASCII format - simple to translate and easy to modify with a word-processor. Probably, one of the early formats (.BRX or .MHR) would be best, because many of us have either adopted one of them, or can translated our own formats to them. I hope the questionnaire will help to identify the most common format. Information on computer type and storage media should be valuable for those who are writing programs and distributing data. PLEASE, send me an example of your data file format if it doesn't fit one of the categories. List the pollen programs you use. They have their own formats. I'll publish the results in an upcoming newsletter, hopefully in time for discussion at the workshop following IPC 8, next September. The questionnaire form is printed on the back of the Newsletter. Please xerox it and send the copy to me today. SCIENTIFIC SOFTWARE FOR APPLE MACINTOSH Pierre A. Zippi 60 Mountview Ave. #410 Toronto, Ontario M6P 2L4 Phone: (416) 766-4077 The Coordinator has asked me to provide descriptions of four Macintosh software products that may be useful to the readers of the INQUA Working Group on Data Handling Methods. The software is written and marketed entirely by me. The software is available at the above address. Make $US checks payable to: Pierre A. Zippi. Add $10 US for shipping and handling to the total order. Ternary Plot, Vector Rose and Counter have been on the market for approximately 4 years; Strat/Range Charter for 6 months. Listings can be found in "The Macintosh Product Directory", Redgate Communications Corp. STRAT/RANGE CHARTER 1.0 Stratigraphic range charts and statistical data preparation. Strat/Range Charter 1.0 is a stratigraphic range charting application that can create large range chart diagrams and ordered species lists from text files containing lists of unique species numbers for each sample horizon. Diagrams can be saved as MacDraw PICT or transferred via the clipboard to any drawtype application. Text and graphic elements are [*p.10 / p.11*] MacDraw-like objects and can be edited with any PICT draw-type application. Strat/Range Charter accepts data created with any word processor or text editor and saved as ordinary text files. A data file is a series of records, or sample horizons. A data record is structured as a sample label followed by a list of species found in that sample. Sequences of samples are plotted in their order of occurrence in the data file. An option is available to reverse the sequence. This produces a relative or sequential scale. Arithmetic or equal spaced scales can be easily created. Diagrams can be sorted by tops, bases, or by the unique species number. Presence/absence charts or total range (range-through) charts can be plotted. Grid lines can be added and the grid line spacing can be specified. Presence/absence data is plotted with a bullet symbol (default), or any keyboard symbol available in the selected font style can be embedded with the data and plotted to indicate abundance, questionable occurrences, reworked specimens, etc. Diagrams can be scaled at nine sizes. From large poster-sized diagrams to very small charts that can viewed entirely on screen. Any font (type-face) installed in the computer system file can be used to display charts and lists. A list of species is compiled for each data file. Species lists can be ordered alphabetically or by unique species number. Separate range charts can be created from the same data file by coding separate types of data with a unique prefix. For example, within the same data file "s110A" could indicate that a spore taxon with the unique species number 110 is present in abundance, while "d110?" could indicate a questionable occurrence of a dinoflagellate species. All unique species numbers, prefix and suffix codes are user defined. Multiple species libraries can be maintained for different types of information. That is, separate libraries can be maintained for foraminifera, dinoflagellates, spores, pollen, etc., or categories can be combined (e.g. all terrestrial palynomorphs in one library and marine palynomorphs in another). Species libraries can be used to create a database. Or, species libraries can be created or updated by exporting species names and numbers from an existing species database. Several database layouts (forms or structures) are provided with the application. Strat/Range Charter 1.0 also prepares presence/absence data matrices and ranked event data which can be used with other statistical software packages for multivariate and nonparametric analysis, respectively. Strat/Range Charter 1.0 is designed to be integrated with computer database and graphics applications. Along with a PICT-type graphics application and a database application, Strat/Range Charter is the keystone element in an integrated stratigraphic range charting computer solution. A PICT-type graphics application such as Claris MacDraw IITM or Deneba CanvasTM and/or a database such as Claris FileMaker ProTM may be bundled or offered with each sale. All Macintoshes. MultiFinder compatible, and System 7 compatible. Price: $1250 US retail. Instructional services and database integration are available on a per day basis (before July, 1992). COUNTER 1.0 Utilize the computer keyboard as an expanded mechanical counter. Counter 1.0 uses the Macintosh keyboard to emulate a mechanical point counter. Scientists and technicians use Counter to count anything from blood cells to mineral grains. The counts (data) are saved as a tab-delimited text file, which is easily imported into spreadsheets such as ExcelTM, or statistical applications such as StatviewTM, etc. Counter 1.0 features an unlimited number of counts and automatic totaling. An audible click indicates that each count is registered. A different audible tone sounds at each multiple of 100 counts. Erroneous counts can be subtracted from any key. Counting keys reset to zero with a single button click. [*p.11 / p.12*] Additional features: 7 keyboard configurations for counting, i.e: -numbers, 0-9 only (10 keys) -single key, zero key (1 key) -lower case, a-z only (26 keys) -upper & lower case, a-Z (52 keys) -all alpha-numerics, 0-9+a-Z (62 keys) -blood count, numeric keys 1-8 with 9 as a non-totalizing key. -full screen, 190 key combinations (all keys, shift + option). Counter 1.0 sells for $100 US. If you doubt the value, remember that an old style 5 slot mechanical counter sells for over $300 and your data still must be typed into the computer! All Macintoshes. MultiFinder compatible, and System 7 compatible. Price: $100 US retail. PC version available too! TERNARY PLOT 3.5 Ternary plotting (triangular diagrams) with text and graphics tools. Ternary Plot 3.5 is a graphic plotting application that normalizes and plots three values on a triangular diagram. Diagrams can be saved as MacDraw PICT or transferred via the clipboard to any draw-type application. Text and graphic elements are MacDraw-like objects and can be edited with a draw-type application. Ternary diagrams can be plotted at four triangle sizes (1.3 inch, 2.6 inch and 4.2 inch sides) or any corner can be enlarged to fill the screen. An unlimited number of data sets can be plotted on the same ternary diagram. The maximum size of any single data set is limited only by the available memory (files with >2000 points can be plotted on a 1mb Mac). Data can be entered into the a ternary plot in four ways: 1) text files, 2) clipboard, 3) keyboard, and 4) created interactively by clicking the mouse pointer within the triangular area. Data entry from all sources is error checked. A diagram title and apex labels can be added or changed at any time. All text can use subscripts and superscripts. Eleven plot symbols plus sample numbers, tie lines, and line segments can be plotted. The same data set can be plotted with symbols, numbers and tie lines to produce a plot of numbered symbols connected by lines. An apex factors option allows values for any corner to multiplied by a factor before normalization. Drawing tools consist of lines, circles, ovals, rectangles, triangles, hexagons, and a freehand pencil. Legends can be easily created with symbols and text from the Legend option. Additional text can be placed anywhere on the diagram. Tick marks and grid lines can be specified from a dialog box. All Macintoshes. MultiFinder, System 7, and A/UX compatible. Tested at MacWorld, Boston. Price: $150 US retail; $40 upgrade from any version. VECTOR ROSE 2.0 Circular normal statistics and rose diagram plotting package. Vector Rose 2.0 is an orientation analysis application that calculates vector (circular normal) statistics and plots a circular histogram for any set of angular data, or any data with a circular normal distribution. Statistics include: number of observations, maximum class frequency, %maximum class frequency, class mode, mean, standard angular deviation, resultant amplitude, vector magnitude, %vector magnitude, Rayleigh test z, and F-test. Diagrams are saved as MacDraw PICT or transferred via the clipboard to other graphics applications. Text and graphic elements are MacDraw-like objects and are fully editable with any draw-type application. Program features include: Unidirectional or bidirectional circular (rose) histograms, class interval arcs scaled relative to modal maximum (length or equal area), or scaled relative to 100%. Axis scales may be represented as concentric circles or as a vertical line with tick marks. Variable class intervals: 1ų, 2ų, 5ų, 10ų, 15ų, 20ų, 25ų, and 30ų. North or 0ų reference can be rotated to any position. Three modes of data entry: 1) text files, 2) clipboard, or 3) keyboard. Keyboard entry of single or multiple values. All data is error checked. Text may be placed anywhere on the diagram. Help screens provide detailed information on the statistics and operation. Vector Rose 2.0 prints high quality output to a LaserWriter or an ImageWriter. Once in a draw [*p.12 / p.13*] application, all elements of the diagram can be edited and diagrams can be re-sized or graphically enhanced. Plotting rose diagrams by hand can be tedious and time consuming. Vector Rose 2.0 will generate publication quality output in a small fraction of the time it would take to calculate the statistics and draft the diagram by hand. All Macintoshes. MultiFinder, System 7, and A/UX compatible. Tested at MacWorld, Boston. Price: $125 US retail; $50 upgrade from any version. DEPTH-AGE CONVERSION OF POLLEN DATA Louis J. Maher, Jr Those working with sediment cores often use sample depth as a proxy for sample age. If radiocarbon dates are available, it is useful to convert depth units into equivalent C-14 years. When I ask my students to do this as an exercise, I have always been fascinated with their attitudes; most will accept without question a carbon date and its stated error. When deeper dates show constant age, or when younger dates lie under older ones, students put absolute trust in nuclear physics and readily discard pollen zone boundaries, principles of superposition, and Ockham's razor. Sediment processes in lakes can be complicated, of course, but there are many reasons way carbon dates can be in wrong as well. A student will often construct a depth-age plot, connect the dates with straight line segments, and use some kind of linear regression to assign ages to the depth samples. This involves a lot of work; it is no small task to convert a pollen diagram from depth to age--let along considering different kinds of regression. Tedious tasks keep us from looking at interesting questions. For one thing, the slope of a line connecting two dates is a measure of the net rate of sedimentation (cm/yr) between the dated points. I recall a student's comment when he noted his sedimentation rates were always constant in the interval from one date to the next, but would then change and become constant again on the way to the next date in sequence. He thought it was neat how the carbon dates had been able to "catch" these rate changes! Partly as a result of that experience, I developed a PC-based program which allows one to make a depth-age plot on a graphics screen. Age can then be regressed on to depth by fitting exponential, power, or nth-order functions, as well as doing linear and cubic splines regressions. Using this program, a student can quickly learn that the same data can be fitted by different functions, and those that are best in one situation may do poorly in another. A function's parameters can be saved in a "rate" file. A rate file can be used to take one of my POLFILE data files ordered by depth and automatically convert it to a file ordered by age. The implied sedimentation rate at each sample level is calculated as well. I call this program DEP-AGE; it functions by reading depth and age data from an ASCII file with the three-letter extension "C14" after its name. I will use a restricted data set from my Devils Lake core as an example of the operation. DEV9WTOP.C14 (short for Devils Lake; 9 samples with the top 0.5 cm assigned the date the core was taken: 1978 AD = -28 BP.) is shown below: Devils Lake, Sauk Co., WI 4 9 MinDepth(cm) 0 164 263 334 395 455 514 541 599 MaxDepth(cm) .5 169 267 338 399 459 518 547 611 C14Age(YrBP) -28 2430 4105 5245 6920 8640 10080 10620 12550 StandDevAge 50 65 65 65 75 85 100 105 132 It consists of a title line, followed by the number of categories (4), and the number of dated points (9). The program assumes all depths will be in centimeters and all ages in years. Each dated interval has a top (MinDepth) and a bottom (MaxDepth) and an age with a standard deviation. In the *.C14 file above, the first actual carbon date came from the interval from 164 to 169 cm in the core; its reported value was 2430 + 65 BP. This kind of file can be made with an ordinary word processor or with POLFILE. If you use POLFILE, first make a RAW file of the four categories: MinDepth, MaxDepth, Age, and StandDevAge. Then make it into a DATA file called ANYNAME.C14. [*p.13 / p.14*] Starting Dep-Age, produces the following menu: 1. Plot Diagram Regressing Age (Years) on to Depth (Centimeters). The program gets data from a '*.C14' file. 2. Information About Making a '*.C14' File. 3. Calculate Age of Sediment Level, Given Depth. Q. Quit! ( Use this to END the Program. ) Choose 1, 2, 3, or Q _ If you select "1" and load DEV9WTOP.C14, the screen will plot the depth-age chart with the nine control points shown in fig. 1. The vertical axis measures core depth with a horizonal line marking each meter. The age is plotted along the horizontal axis with a vertical line every 1000 years. The control-point symbols on the screen show the mean age plus or minus two standard deviations. The depth midway between the upper and lower limits is used in the regression. (When curves are fit by least-squares regression, age is regressed on to depth; the figure is oriented with the depth axis vertical because that seems natural for a lake core.) Touch any key and the following screen appears: Results of DEP-AGE.EXE Devils Lake, Sauk Co., WI N-categories = 4 N-samples = 9 CATEGORIES IN FILE: DEV9WTOP.C14 MinDepth(cm) MaxDepth(cm) C14Age(YrBP) StandDevAge 1. SHOW Diagram of Site. 2. TOGGLE Graph ORIGIN Top to Bottom. 3. FIT Nth ORDER CURVE to Control Points. 4. FIT EXPONENTIAL CURVE to Control Points. 5. FIT POWER CURVE to Control Points. 6. FIT CUBIC SPLINE to Control Points. 7. INTERPOLATE LINEARLY between Control Points. 8. **SAVE CURVE DATA TO A DISK FILE** 9. CHANGE Site. C. Change COLORS of Screen. Q. QUIT and Return to First Menu. Press 1 - 9 , C, or Q _ Picking "7" produces the chart shown in fig. 2. Because these lines are one measure of sedimentation rate (cm/yr) in the core, it may help if rates are drawn with positive slopes. In that case touch "2", and the graph is redrawn so that both depth and time increase up and right (fig. 3). (My student would note that the carbon dates had again miraculously captured the places where the sedimentation rates changed.) Touch any key again to return to the menu. Cubic splines are often used in depth-age plots because the spline fit passes through all the control points, bending smoothly to do so. In the jargon of the trade, the spline curve depends on the second derivatives of the interpolating function at the control points. Splines can do a convincing job of showing the trend of the data; the sedimentation rates (line slopes) change gradually and avoid the sudden changes that characterize linear segments (fig. 4). However, they do not always work. When dates change rapidly over short depth intervals, the spline curve may develop graceful ruffle-like bends which contain [*p.14 / p.15*] vertical sections that bend back on themselves; infinite rates and negative sedimentation rates are difficult to handle. Linear and spline fits presume the dates are perfect, but in the real world that is not going to be true. The standard deviations assigned to dates usually speak only to the uncertainty owing to random counting error; if a normal distribution is assumed, there is one chance in three that the true value lies outside the published range. And there are many other reasons to distrust a carbon date. That is the main reason I like to use least-squares techniques to fit age to depth. We assume there is a relationship between the two, and we are pretty confident in our depth measurements, but we do not know which dates are correct. Then too, with least-squares fits, we can calculate correlation coefficients that help us judge the "goodness of fit." Touching "4" or "5" will fit, respectively, exponential or power functions to the data. These functions were commonly used before computers; exponential functions plot as straight lines on semi-log paper, and power functions plot as straight lines on log-log paper. Exponential rates are common in Nature, but relatively rare in sedimentation. Power functions often do a reasonable job in describing sedimentation. Both are "unidirectional," and this agrees with our prejudice that as sediments go deeper, they should get older. I like to pick "3" and fit an nth-order function to the control points. Recall that a first-order function is a straight line, a 2nd-order function is either convex or concave, but does not change between the two. In general, nth-order polynomials have n-1 bends, and this helps us predict what order will be required to match the data. Assume that you pressed "3." You will be asked what degree of equation is to be fitted (i.e. 1, 2, 3 ...). If you select 2, the following will appear on the screen: [ control points not shown here ] Constant = 2.612551 1 Degree coefficient = 11.15511 2 Degree coefficient = 1.585796E-02 Coefficient of determination (R-squared) = .9986199 Coefficient of determination = .9993097 Standard error of estimate = 177.6288 Perhaps you have shared with me the humiliation of hearing a colleague talk about fitting a 5th-order function to his/her dates, when you could not do the math. Without a computer and the right program, one is restricted to sketching on log paper or fitting curves by "eye-ball." DEP-AGE lets you do reconnaissance curve-fitting in the privacy of your PC. Fitting a mathematical curve to the data by regression does not imply that the lake "has a memory" such that its early sedimentation rate predicts later values. Rather, we try to choose a reasonable function and then fit it so that its deviation from all the control points is minimized. A 5th-order curve does a good job of running a smooth line near most of the dates in the DEV9WTOP.C14 file. But a 2nd-order polynomial does almost as well (fig. 5). I tend to experiment by fitting a variety of curves, then taking the lowest order than does a reasonable job. The curve in fig. 5 passes through the error boxes of eight of the nine control points, and it grazes the ninth. You will note DEP-AGE's menu has the option "8. **SAVE CURVE DATA TO A DISK FILE**." After you experiment fitting curves to your data, you have the op- portunity of saving the results to disk in a [*p.15 / p.16*] summary "rate" file; for example: "DV-SPLIN.RAT". It will include the site's title, the control points, the calculated parameters of the curve, and, if available, the various regression coefficients. You will want to save rate files with distinctive names for any of the experimental fits that seem promising. The *.rat file serves the purpose not only for documentation, but also for use by DEP-AGE; it contains all that is needed to solve for predicted sediment age in years BP, given its depth in centimeters. For example, the rate file for the 2nd-order fit to these data was named "DV-2ND.RAT" and is reproduced below: Devils Lake, Sauk Co., WI 01-05-1992 Control Points = 9 Polynomial of degree 2 Constant = 2.612551 1 Degree coefficient = 11.15511 2 Degree coefficient = 1.585796E-02 Coefficient of determination (R-squared) = .9986199 Coefficient of determination = .9993097 Standard error of estimate = 177.6288 Control Points Sample DEPTH Sample AGE 0.3 -28 166.5 2430 265.0 4105 336.0 5245 397.0 6920 457.0 8640 516.0 10080 544.0 10620 605.0 12550 The *.RAT file varies somewhat for each different function fit to the data, but is basically self-explanatory. It is an ASCII text file that can be examined easily. However, avoid editing a *.RAT file because DEP-AGE uses the format to recognize the function and read the parameters. After saving a *.RAT file, press "Q" to return to the first menu. When you then select "3. Calculate Age of Sediment Level, Given Depth," you will be asked for the name of the desired *.RAT file. Assuming it is DV-2ND.RAT, when the file is read, the computer screen will show the function's parameters at the top, whereas instructions and the depth of lowest control point are at the bottom. (Remember: only a fool extrapolates a polynomial curve outside the range of its control points.) Devils Lake, Sauk Co., WI 01-05-1992 Control Points = 9 Fit to Polynomial of degree 2 Constant = 2.612551 1 Degree coefficient = 11.15511 2 Degree coefficient = 1.585796E-02 (R-squared) = .9986199 Depth(cm) = 600 Age = 12405 Cm/Yr = 0.0331 Depth(cm) = 500 Age = 9545 Cm/Yr = 0.0370 Depth(cm) = 400 Age = 7002 Cm/Yr = 0.0419 Depth(cm) = 300 Age = 4776 Cm/Yr = 0.0484 Depth(cm) = ---------------------- ENTER DEPTH IN CENTIMETERS TO ESTIMATE C14 AGE [ CR ALONE TO EXIT ] Lowest control point is 605 centimeters. ---------------------- When the depth value is typed, the predicted age is supplied along with an estimate of the sedimentation rate at that depth. The sedimentation rate (cm/yr) is taken as the reciprocal of the difference in estimated age at the top and base of the 1-cm interval centered on the specified depth. I use this method rather than reporting rate as the tangent to the curve at the specified depth; most sediment samples are not dimensionless "point" samples. This screen allows one to try a few values to test the general results of the function. Pressing "enter" or "carriage return" without specifying a depth, gets you back to the initial menu, but you are first given the opportunity of converting one of POLFILE's data files ordered by depth to a *.DAT file ordered by age in years. (An alternate choice is age in decades; see below.) My *.DAT files have a title, an integer representing NP, the number of pollen taxa, and an integer representing NS, the number of samples. Given this information, an array of pollen data can be read for computer processing; the actual distance (depth) between the samples is often not needed. But I include ordinal data at the end of the pollen data. If such data are required, the program expects to find this information after the pollen data; it merely reads in NS values of depth. But there is no reason why these NS values must be depth; they might well be years or decades. My program PLOTSITE reads a *.DAT file, and it normally reads the extra ordinal sample depths (cm) to use in plotting a simple pollen diagram. PLOTSITE defines the y-axis by plotting a short marker at 100-cm intervals. Now if the ordinal depth units were replaced with age in decades, PLOTSITE's y-axis indicators will mark off 100 decades or 1000 years. Figure 6 represents a restricted data set from Devils Lake whose core is a little over 6 meters long. Figure 7 shows the same data, but with the y-axis scaled in 1000's of years based on the 2nd order fit of DV-2ND.RAT. A fragment of the original file follows: Devils Lake, Sauk Co., WI 12 31 Picea 1 0 0 0 1 1 1 0 0 1 0 0 1 1 0 0 1 1 1 0 1 0 2 23 30 129 188 127 196 264 225 ...[10 taxa deleted]... [*p.16 / p.17*] Other Terrestrial Types 78 70 68 50 80 69 54 55 53 70 56 75 62 49 58 87 117 86 79 89 176 103 106 213 110 220 163 311 149 142 98 Depth (cm) .5 19.5 46.5 76.5 104.5 130.5 154 174 194 214 234 259 278 298 318 344 364 384 404 430 449 469 489 509 535 554 570 584 598 608 628 'Subset of Devils Lake core for Newsletter' The derived *.dat file ordered by age contains additional information: .... Other Terrestrial Types 78 70 68 50 80 69 54 55 53 70 56 75 62 49 58 87 117 86 79 89 176 103 106 213 110 220 163 311 149 142 98 Estimated Age in Decades BP 1 23 56 95 134 173 210 242 276 312 348 396 433 474 515 572 616 662 710 773 821 872 925 979 1051 1105 1151 1193 1234 1265 1326 Estimated Sedimentation rate in cm/yr .089 .085 .079 .074 .069 .065 .062 .06 .058 .056 .054 .052 .05 .049 .047 .045 .044 .043 .042 .040 .039 .038 .038 .037 .036 .035 .034 .034 .033 .033 .032 Depth (centimeters) .5 19.5 46.5 76.5 104.5 130.5 154 174 194 214 234 259 278 298 318 344 364 384 404 430 449 469 489 509 535 554 570 584 598 608 628 'Subset of Devils Lake core for Newsletter' Age in Decades were converted from original Depth(cm) by the following: Devils Lake, Sauk Co., WI 01-05-1992 Control Points = 9 Polynomial of degree 2 Constant = 2.612551 1 Degree coefficient = 11.15511 2 Degree coefficient = 1.585796E-02 Coefficient of determination (R-squared) = .9986199 Coefficient of determination = .9993097 Standard error of estimate = 177.6288 Control Points Sample DEPTH Sample AGE 0.3 -28 166.5 2430 265.0 4105 336.0 5245 397.0 6920 457.0 8640 516.0 10080 544.0 10620 605.0 12550 The sample ages and sedimentation data are added after the pollen data, and the original depths and the *.RAT file are appended for purposes of documen- tation. A word processor can be used to cut/copy the derived ages and sedimentation rates from the file to be pasted into a file for use with Craig Chumbley's PALYPLOT. Or the *.DAT file can be edited with POLFILE to Eric Grimm's "Wisconsin" format for importation into TILIA. I would be happy to provide a free copy of DEP-AGE, POLFILE, and PLOTSITE, if you provide me with a blank formatted disk, tell me what kind of graphic screen you use (EGA, VGA, or MCGA), and whether you have a color or black and white monitor. References Chumbley, C. A. 1991. PALYPLOT: A PC-based program for plotting pollen and plant macrofossil stratigraphic data. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods Newsletter 5: 2-4. Grimm, E. C. 1990. TILIA and TILIAłGRAPH: PC spreadsheet and graphics software for pollen data. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods Newsletter 4: 5-7. Maher, L. J., Jr. 1990. Programs useful in the pollen lab. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods Newsletter 4: 7-10. [*p.17 / p.18*] FIRST AID FOR TILIA AND PALYPLOT USERS by Dr. Triage The Newsletter Coordinator told me my column in the last issue generated enough interest that he would let me have space again for the questions I thought of value to the readers. We felt new users of TILIA and TILIAłGRAPH (Grimm, see Newsletter 4, July 1990) and PALYPLOT (Chumbley, see Newsletter 5, January 1991) might rather put their questions to an intermediary rather than the expert who made the program. Therefore, if you mail or e-mail questions to Lou Maher (address on p. 1), he will relay them to me for a quick response. If I do not know the answer, I will refer them to the appropriate expert. Remember, I can do this column only while you send questions. TILIA and TILIAłGRAPH Dr. Triage: I have data from dozens of pollen sites that I keep in QUATTRO PRO spreadsheet files. Can I read these files with TILIA? Hopeful. Dear Hopeful: There are several ways to do it. I will give you my favorite which should be easy because you already know your spreadsheet. Arrange your spreadsheet's columns and rows to look like the following (partial) dataset as you view it IN YOUR SPREADSHEET. Depth(cm) Picea Quercus ... Compositae 1 0 150 ... 50 50 1 259 ... 21 100 0 350 ... 18 ... ... ... ... ... 1100 349 0 ... 115 That is, the ROW across the top contains words (text strings), STARTING WITH THE SAMPLE DEPTH, and followed by the taxa in your file. The remaining rows will contain the raw counts for each sample in the core. Save the spreadsheet as a file ending with ".WK1", such as MYFILE.WK1. LOTUS 123 adds that extension by default. As a QUATTRO PRO user, you know its default extension is ".WQ1". However, QUATTRO PRO does have a "Save As" option whereby you can give the file name AND the extension. If you stipulate "MYFILE.WK1" the file will be saved in a form that can be read by TILIA or LOTUS 123. I assume you now have altered your spreadsheet and saved it with the proper extension. Now start up TILIA. From the menu, pick [I] Options | [A] Working Directory, and give the directory in which "MYFILE.WK1" is located. Escape to the main menu again, this time selecting [C] Load data file | [H] WKS or WK1 format. You will be asked for a file name. Press the key, and you will see all the files in your directory; this is a new feature in the last release. Select "MYFILE.WK1". You will see a box: Read Column Labels into [A] Variable Name [B] Variable Code Name Pick [A] Variable NAME. Another box appears: [A] Named Range [B] Specify Range [C] Default Range Pick [C] and a box shows the columns and rows being read. ([A] and [B] allow you to load only part of a spreadsheet.) When you are returned to the main menu, pick [A] Spreadsheet, and you should see your file in TILIA's format: (depths) 1 50 100 ... 1100 Picea 0 1 0 349 Quercus 150 259 350 ... 0 ... ... ... ... ... ... Compositae 50 21 18 ... 115 Note the array order of the spreadsheet is transposed in TILIA. Note also that the taxa in the TILIA spreadsheet are shown as letters A, B, C ... although when you are in any row, the taxon name for that row is displayed at the lower left of the screen. D.T. Dr. Triage: How does one correct spelling errors in the diagram heading menu of TILIAłGRAPH? The arrow keys only move from field to field. Must one retype the whole line? Also, once I set up all the diagram styling features I like, is there some way I can retain those features as defaults when I load in data from another site? Slow Typist. Dear Slow: Apparently one must retype the line (or DELETE from the beginning of the line until the error is [*p.18 / p.19*] removed, and then insert the corrected material). Eric allows you edit the label for the Y-axis, and I would think he could also let the headings be edited. As things stand now, you cannot save a "style template" to be used with different cores. It may be possible to alter certain favorite default settings so that graph types, patterns, scale dots, etc. can be specified in advance, but Eric has not told us how to do it. The *.TIL file simply records the taxa and the numbers. TILIAłGRAPH converts this into the *.TGF file which contains all the information for turning the material into a diagram--including the extra material you have specified. If you have a working *.TGF file, DO NOT let it be overwritten the next time you change to TILIAłGRAPH from TILIA after loading a *.TIL file. Say you have loaded MUDLAKE.TIL. You will be asked what you want to call the *.TGF file, and the name MUDLAKE.TGF will be suggested. At his point type in a different name (the word MUDLAKE will disappear as soon as you touch a letter key), and if you keep track of the names you use, you will not destroy a working diagram that you have already created. I keep a special floppy disk of *.TGF files and move *.TGF files to it from the DATA sub-directory. You can make a *.TGF file from a *.TIL file. You can reload an old *.TGF file and further edit fonts, patterns, etc., and they will be saved when you are done; but you can not change its numbers. When you load a new *.TIL file, you start from scratch. D.T. Dr. Triage: I have a problem that prevents me from sleep; it is driving me to distraction. I am trying to make TILIAłGRAPH show a summary plot of the four categories Trees & Shrubs, Herbs, Pteridophytes, and Dwarf Shrubs, displaying them so that their abundance in each level sums to 100 %. I have done this using [D] Edit | F3, to define the four groups I wish to plot cumulatively. But when I make and view the diagram, where I want the cumulative graph to be plotted summed to 100 %, the program leaves space for 150 %. I am sending you a disk with the problem file. A Remedy! Dear Remedy: It does the same thing for me, and now I can not sleep either. I am sending the disk on to Eric Grimm. Dear A. Remedy: Your problem was passed on to me by Dr. Triage. I was able to duplicate the problem with several curves that add to 100 %. I had tried 3 or 4 curves before, and it had always worked. Anyway, the problem is caused by what I suspected. Because of rounding error, one or more of the level totals adds up to slightly more than 100 %; therefore the next tic mark is placed at 150 %. The fix is to set the axis limits for the base graph manually. The base graph is the first graph, in your case, Trees & Shrubs. (1) Make menu selections [Axes | X-axes | Modify single graph] (2) Select the base graph (3) Select [Axis limits] (4) Set the Maximum to 100 That should do it. Cheers, Eric. PALYPLOT Dr. Triage: I would like to use PALYPLOT to show summary diagrams from three separate sites stacked one above the other on a page. Their spectra are quite different. Is there any easy way to control the spacing so that each taxon is lined up in all three diagrams? Fred. Dear Fred: There is no easy way, but it can be done. Recall that PALYPLOT uses files that have exactly the same format as Maher's ".DAT" files, but Craig Chumbley uses the extension ".PDT". Put copies of the three ".PDT" files you want to use in a temporary directory. Change the extension names to ".DAT". Use Maher's POLFILE to convert the ".DAT" files to the "Wisconsin" format as if you were going to import them into TILIA. The "Wisconsin" format is Maher's ".RAW" file; it has the pollen data in sequence for each level from top to bottom, and the first item in each level is the sample depth. Load the three ASCII text files into a wordprocessor and trim them so that there is a single title, followed by the number of taxa (NP) on the second line, and on the third line put the number of samples (NS) in all three files. Cut Title, NP, and NS from the second and third files. Cut the list of taxa from the first and second files. Now code the depths of the second and third files. If the first file ends at 700 cm, add 750 to each depth in the second file. This will put a space between the two, equivalent to 50 cm. If the lowest sample in the second file has a coded depth of 1350, add 50 to it and add 1400 to each depth in the third file. You will now have one complete "Wisconsin" format file which should be saved as an ASCII text file under a new name. Use POLFILE to change the [*p.19 / p.20*] new combined ".RAW" file into a ".DAT" file. When you are asked for the taxon names, pick the choice that lets you get the names automatically by reading them from one of the three original ".DAT" files. When you save the file, specify ".PDT" as the exten- sion. It can then be read directly into PALYPLOT. Choose the "line" graph style, and import the result into Generic CADD. Use the CADD program's editing function OB (object break) to cut and entirely remove the left (zero) margin of each curve. This nicely separates the three diagrams, and only a little editing needs to be done to restore the cores' correct depth labels. D.T. [ Email addresses (not reproduced) extend on to p. 21 ] [ Questionnaire on p. 22 not reproduced. ]