Frequently Asked Questions

Problems that are encountered
How to make it do various things:
Background information needed:
Questions about distribution and citation:
Questions about documentation
Additional Frequently Asked Questions, or: "Why didn't it occur to you to ...
(Fortunately) obsolete questions

Problems that are encountered

"It doesn't work! It doesn't work!! It says can't find infile."

Actually, it's working just fine. Many of the programs look for an input file called infile, and if one of that name is not present in the current folder, they then ask you to type in the name of the input file. That's all that it's doing. This is done so that you can get the program to read the file without you having to type in its name, by making a copy of your input file and calling it infile. If you don't do that, then the program issues this message. It looks alarming, but really all that it is trying to do is to get you to type in the name of the input file. Try giving it the name of the input file.

"The program reads my data file and then says it's has a memory allocation error!"

This is what tends to happen if there is a problem with the format of the data file, so that the programs get confused and think they need to set aside memory for 1,000,000 species or so. The result is a "memory allocation error" (the error message may say that "the function asked for an inappropriate amount of memory"). Check the data file format against the documentation: make sure that the data files have not been saved in the format of your word processor (such as Microsoft Word) but in a "flat ASCII" or "text only" mode. Note that adding memory to your computer is not the way to solve this problem -- you probably have plenty of memory to run the program once the data file is in the correct format.

"On our MacOS 9 system, larger data files fail to run."

We have set the memory allowances on the MacOS 9 executables to be generous, but not too big. You therefore may need to increase them. Use the Get Info item on the Finder File menu.

"I opened the program but I don't see where to create a data file!"

The programs (there are more than one) use data files that have been created outside of the program. They do not have any data editor within them. You can create a data file by using an editor, such as Microsoft Word, EMACS, vi, SimpleText, Notepad, etc. But be sure not to save the file in Microsoft Word's own format. It should be saved in Text Only format. You can use the documentation files, including the examples at the end of those files, to figure out the format of the input file. Documentation files such as main.html, sequence.html, distance.html and many others should be consulted. Many users create their data files by having their alignment program (such as ClustalW), output its alignments in PHYLIP format. Many alignment programs have options to do that.

"I ran PHYLIP, and all it did was say it was extracting a bunch of files!"

There is no executable program named PHYLIP in the PHYLIP package! But in some cases (especially the Windows distribution) there is a file called phylip.exe. That file is an archive of documentation and source code. Once you have run it and extracted the files in it, so that they are in the folder, running it again will just do the extraction again, which is unnecessary. Similarly for the archive files for the Windows executables, which have names like phylipwx.exe and phylipwy.exe. They are run only once to extract their contents.

"One program makes an output file and then the next program crashes while reading it!"

Did you rename the file? If a program makes a file called outfile, and then the next program is told to use outfile as its input file, terrible things will happen. The second program first opens outfile as an output file, thus erasing it. When it then tries to read from this empty outfile a psychological crisis ensues. The solution is simply to rename outfile before trying to use it as an input file.

"I make a file called infile and then the program can't find it!"

Let me guess. You are using Windows, right? You made your file in Word or in Notepad or WordPad, right? If you made a file in one of these editors, and saved it, not in Word format, but in Text Only format, then you were doing the right thing. But when you told the operating system to save the file as infile, it actually didn't. It saved it as infile.txt. Then just to make life harder for you, the operating system is set up by default to not show that three-letter extension to the file name. Next to its icon it will show the name infile. So you think, quite reasonably, that there is a file called infile. But there isn't a file of that name, so the program, quite reasonably, can't find a file called infile. If you want to check what the actual file name is, use the Properties menu item of the File item on your folder (in Windows versions, anyway). You should be able to get the program to work by telling it that the file name is infile.txt.

"Consense gives weird branch lengths! How do I get more reasonable ones?"

Consense gives branch lengths which are simply the numbers of replicates that support the branch. This is not a good reflection of how long those branches are estimated to be. The best way to put better branch lengths on a consensus tree is to use it as a User Tree in a program that will estimate branch lengths for it, such as DnaML. You may need to convert it to being an unrooted tree, using Retree, first. If the original program you were using was a program that does not estimate branch lengths, you may instead have to use one that does. You can use a likelihood program, or make some distances between your species (using, for example, DNADIST) and use FITCH to put branch lengths on the user tree. Here is the sequence of steps you should go through:
  1. Take the tree and use Retree to make sure it is Unrooted (just read it into Retree and then save it, specifying Unrooted)
  2. Use the unrooted tree as a User Tree (option U) in one of our programs (such as FITCH or DNAML). If you use FITCH, you also first need to use one of the distance programs such as DNADIST to compute a set of distances to serve as its input.
  3. Specify that the branch lengths of the tree are not to be used but should be re-estimated. This is actually the default.

"I looked at the tree printed in the output file outfile and it looked weird. Do I always need to look at it in Drawgram?"

It's possible you are using the wrong font for looking at the tree in the output file. The tree is drawn with dashes and exclamation points. If a proportional font such as Times Roman or Helvetica is used, the tree lines may not connect. Try selecting the whole tree and setting the font to a fixed-width one such as Courier. You may be astounded how much clearer the tree has become.

"DrawTree (or DrawGram) doesn't work: it can't find the font file!"

Six font files, called font1 through font6, are distributed with the executables (and with the source code too). The program looks for a copy of one of them called fontfile. If you haven't made such a copy called fontfile it then asks you for the name of the font file. If they are in the current folder, just type one of font1 through font6. The reason for having the program look for fontfile is so that you can copy your favorite font file, call the copy fontfile, and then it will be found automatically without you having to type the name of the font file each time.

"Can DrawGram draw a scale beside the tree? Print the branch lengths as numbers?"

It can't do either of these. Doing so would make the program more complex, and it is not obvious how to fit the branch length numbers into a tree that has many very short internal branches. If you want these scales or numbers, choose an output plot file format (such as Postscript, PICT or PCX) that can be read by a drawing program such as Adobe Illustrator, Freehand, Canvas, CorelDraw, or MacDraw. Then you can add the scales and branch length numbers yourself by hand. Note the menu option in DrawTree and DrawGram that specifies the tree size to be a given number of centimeters per unit branch length.

"How can I get DrawGram or DrawTree to print the bootstrap values next to the branches?"

When you do bootstrapping and use Consense, it prints the bootstrap values in its output file (both in a table of sets, and on the diagram of the tree which it makes). These are also in the output tree file of Consense. There they are in place of branch lengths. So to get them to be on the output of DrawGram or DrawTree, you must write the tree in the format of a drawing program and use it to put the values in by hand, as mentioned in the answer to the previous question.

"I have an HP laser printer and can't get DrawGram to print on it"

DRAWGRAM and DRAWTREE produce a plot file (called plotfile): they do not send it to the printer. It is up to you to get the plot file to the printer. If you are running Windows this can probably be done with the Command tool and the command COPY/B PLOTFILE PRN:, unless your printer is a networked printer. The /B is important. If it is omitted the copy command will strip off the highest bit of each byte, which can cause the printing to fail or produce garbage.

"DNAML won't read the treefile that is produced by DNAPARS!"

That's because the DNAPARS tree file is a rooted tree, and DNAML wants an unrooted tree. Try using Retree to change the file to be an unrooted tree file. Our most recent versions of the programs usually automatically convert a rooted tree into an unrooted one as needed. But the programs such as DNAMLK or DOLLOP that need a rooted tree won't be able to use an unrooted tree.

"In bootstrapping, SEQBOOT makes too large a file"

If there are 1000 bootstrap replicates, it will make a file 1000 times as long as your original data set. But for many methods there is another way that uses much less file space. You can use SEQBOOT to make a file of multiple sets of weights, and use those together with the original data set to do bootstrapping.

"In bootstrapping, the output file gets too big."

When running a program such as NEIGHBOR or DNAPARS with multiple data sets (or multiple weights) for purposes of bootstrapping, the output file is usually not needed, as it is the output tree file that is used next. You can use the menu of the program to turn off the writing of trees into the output file. The trees will still be written into the output tree file.

"Why don't your programs correctly read the sequence alignment files produced by ClustalW?"

They do read them correctly if you make the right kind. Files from ClustalV or ClustalW whose names end in ".aln" are not in PHYLIP format, but in Clustal's own format which will not work in PHYLIP. You need to find the option to output PHYLIP format files, which ClustalW and ClustalV usually assign the extension .phy.

"Why doesn't NEIGHBOR read my DNA sequences correctly?"

Because it wants to have as input a distance matrix, not sequences. You have to use DNADIST to make the distance matrix first.

How to make it do various things

"How do I bootstrap?"

The general method of bootstrapping involves running SEQBOOT to make multiple bootstrapped data sets out of your one data set, then running one of the tree-making programs with the Multiple data sets option to analyze them all, then running CONSENSE to make a majority rule consensus tree from the resulting tree file. Read the documentation of SEQBOOT to get further information. Before, only parsimony methods could be bootstrapped. With this new system almost any of the tree-making methods in the package can be bootstrapped. It is somewhat more tedious but you will find it much more rewarding.

"How do I specify a multi-species outgroup with your parsimony programs?"

It's not a feature but is not too hard to do in many of the programs. In parsimony programs like MIX, for which the W (Weights) and A (Ancestral states) options are available, and weights can be larger than 1, all you need to do is:
In MIX, make up an extra character with states 0 for all the outgroups and 1 for all the ingroups. If using
DNAPARS the ingroup can have (say) G and the outgroup A.
Assign this character an enormous weight (such as Z for 35) using the W option,
all other characters getting weight 1, or whatever weight they had before.
If it is available, Use the A (Ancestral states) option to designate that for that new character the state found in the
outgroup is the ancestral state.
(d)In MIX do not use the O (Outgroup) option.
After the tree is found, the designated ingroup should have been held together by the fake character. The tree will be
rooted somewhere in the outgroup (the program may or may not have a preference for one place in the outgroup over another).
Make sure that you subtract from the total number of steps on the tree all steps in the new character.
In programs like DNAPARS, you cannot use this method as weights of sites cannot be greater than 1. But you do an analogous trick, by adding a largish number of extra sites to the data, with one nucleotide state ("A") for the ingroup and another ("G") for the outgroup. You will then have to use RETREE to manually reroot the tree in the desired place.

"How do I force certain groups to remain monophyletic in your parsimony programs?"

By the same method as in the previous question, using multiple fake characters, any number of groups of species can be forced to be monophyletic. In MOVE, DOLMOVE, and DNAMOVE you can specify whatever outgroups you want without going to this trouble.

"How can I reroot one of the trees written out by PHYLIP?"

Use the program RETREE. But keep in mind whether the tree inferred by the original program was already rooted, or whether you are free to reroot it without changing its meaning.

"What do I do about deletions and insertions in my sequences?"

The molecular sequence programs will accept sequences that have gaps (the "-" character). They do various things with them, mostly not optimal. DNAPARS counts "gap" as if it were a fifth nucleotide state (in addition to A, C, G, and T). Each site counts one change when a gap arises or disappears. The disadvantage of this treatment is that a long gap will be overweighted, with one event per gapped site. So a gap of 10 nucleotides will count as being as much evidence as 10 single site nucleotide substitutions. If there are not overlapping gaps, one way to correct this is to recode the first site in the gap as "-" but make all the others be "?" so the gap only counts as one event. Other programs such as DNAML and DNADIST count gaps as equivalent to unknown nucleotides (or unknown amino acids) on the grounds that we don't know what would be there if something were there. This completely leaves out the information from the presence or absence of the gap itself, but does not bias the gapped sequence to be close to or far from other gapped or ungapped sequences. So it is not necessary to remove gapped regions from your sequences, unless the presence of gaps indicates that the region is badly aligned.

"How can I produce distances for my data set which has 0's and 1's?"

You can't do it in a simple and general way, for a straightforward reason. Distance methods must correct the distances for superimposed changes. Unless we know specifically how to do this for your particular characters, we cannot accomplish the correction. There are many formulas we could use, but we can't choose among them without much more information. There are issues of superimposed changes, as well as heterogeneity of rates of change in different characters. Thus we have not provided a distance program for 0/1 data. It is up to you to figure out what is an appropriate stochastic model for your data and to find the right distance formulas.

"I have RFLP fragment data: which programs should I use?"

This is a more difficult question than you may imagine. Here is quick tour of the issues:
  • You can code fragment presence/absence as 0 and 1 and use a parsimony program. It is not obvious in advance whether 0 or 1 is ancestral, though it is likely that change in one direction is more probable than change in the other for each fragment. One can use either Wagner parsimony (programs MIX, PENNY or MOVE) or use Dollo parsimony (DOLLOP, DOLPENNY or DOLMOVE) with the ancestral states all set as unknown ("?"). The Wagner parsimony model allows change in both directions. Dollo parsimony allows more change in one direction than the other, and if the ancestral state is unknown it lets the data determine which way allows more change.
  • You can use a distance matrix method using the RFLP distance of Nei and Li (1979). Their restriction fragment distance is available in our program RestDist.
  • You should be very hesitant to bootstrap RFLP's. The individual fragments do not evolve independently: a single nucleotide substitution can eliminate one fragment and create two (or vice versa).
For restriction sites (rather than fragments) life is a bit easier: they evolve nearly independently so bootstrapping is possible and RESTML can be used, as well as restriction sites distances computed in RESTDIST. Also directionality of change is less ambiguous when parsimony is used. A more complete tour of the issues for restriction sites and restriction fragments is given in chapter 15 of my book (Felsenstein, 2004).

"Why don't your parsimony programs print out branch lengths?"

Well, DNAPARS and PARS can. The others have not yet been upgraded to the same level. The longer answer is that it is because there are problems defining the branch lengths. If you look closely at the reconstructions of the states of the hypothetical ancestral nodes for almost any data set and almost any parsimony method you will find some ambiguous states on those nodes. There is then usually an ambiguity as to which branch the change is actually on. Other parsimony programs resolve this in one or another arbitrary fashion, sometimes with the user specifying how (for example, methods that push the changes up the tree as far as possible or down it as far as possible). Our older programs leave it to the user to do this. In DNAPARS and PARS we use an algorithm discovered by Hochbaum and Pathria (1997) (and independently by Wayne Maddison) to compute branch lengths that average over all possible placements of the changes. But these branch lengths, as nice as they are, do not correct for mulitple superimposed changes. Few programs available from others currently correct the branch lengths for multiple changes of state that may have overlain each other. One possible way to get branch lengths with nucleotide sequence data is to take the tree topology that you got, use RETREE to convert it to be unrooted, prepare a distance matrix from your data using DNADIST, and then use FITCH with that tree as User Tree and see what branch lengths it estimates.

"Why can't your programs handle unordered multistate characters?"

In this 3.6 release there is a program PARS which does parsimony for undordered multistate characters with up to 8 states, plus ?. The other the discrete characters parsimony programs can only handle two states, 0 and 1. This is mostly because I have not yet had time to modify them to do so - the modifications would have to be extensive. Ultimately I hope to get these done. If you have four or fewer states and need a feature that is not in PARS, you could recode your states to look like nucleotides and use the parsimony programs in the molecular sequence section of PHYLIP, or you could use one of the excellent parsimony programs produced by others.

Background information needed:

"What file format do I use for the sequences?"
"How do I use the programs? I can't find any documentation!"

These are discussed in the documentation files. Do you have them? You probably do. They are in a separate archive from the executables (they are in the Documentation and Sources archives, which you should definitely fetch). Input file formats are discussed in main.html, in sequence.html, distance.html, contchar.html, discrete.html, and the documentation files for the individual programs.

"Where can I find out how to infer phylogenies?"

There now a few books. For molecular data you could use one of these: At the upper-undergraduate level:
  • Graur, D. and W.-H. Li. 2000. Fundamentals of Molecular Evolution. Sinauer Associates, Sunderland, Massachusetts. (or the earlier edition by Li and Graur).
  • Page, R. D. P. and E. C. Holmes. 1998. Molecular Evolution: A Phylogenetic Approach. Blackwell, Oxford.

and as graduate-level texts:

  • Nei, M. and S. Kumar. 2000. Molecular Evolution and Phylogenetics. Oxford University Press, Oxford.
  • Li, W.-H. 1999. Molecular Evolution. Sinauer Associates, Sunderland, Massachusetts.

For more mathematically-oriented readers, there is the book

  • Semple, C., and M. Steel. 2003. Phylogenetics. Oxford Lecture Series in Mathematics and Its Applications, volume 24. Oxford University Press, Oxford.

Best of all is of course my own book on phylogenies, which covers the subject for many data types, at a graduate course level:

  • Felsenstein, J. 2004. Inferring Phylogenies. Sinauer Associates, Sunderland, Massachusetts.

There are also some recent books that take a more practical hands-on approach, and give some detailed information on how to use programs, including some PHYLIP programs. These include:

  • Hall, B. G. 2004. Phylogenetic Trees Made Easy, 2nd edition. Sinauer Associates, Sunderland, Massachusetts.
  • Salemi, M., and A.-M. Vandamme (eds.) 2003. The Phylogenetic Handbook. A Practical Approach to DNA and Protein Phylogeny. Cambridge University Press, Cambridge.

A useful article introducing the inference of phylogenies at a more elementary level is:

  • Baldauf, S. L. 2003. Phylogeny for the faint of heart: a tutorial. Trends in Genetics 19: 345-351.

There is an excellent guide to using PHYLIP 3.6 for molecular analyses available. It is by Jarno Tuimala:

  • Tuimala, J. 2004. A Primer to Phylogenetic Analysis using Phylip Package. 2nd edition. Center for Scientific Computing, Espoo, Finland.
and it is available as a PDF

In addition, one of these three older review articles may help:

Questions about distribution and citation:

"If I copied PHYLIP from a friend without you knowing, should I try to keep you from finding out?"

No. It is to your advantage and mine for you to let me know. If you did not get PHYLIP "officially" from me or from someone authorized by me, but copied a friend's version, you are not in my database of users. You may also have an old version which has since been substantially improved. I don't mind you "bootlegging" PHYLIP (it's free anyway), but you should realize that you may have copied an outdated version. If you are reading this Web page, you can get the latest version just as quickly over Internet. It will help both of us if you get onto my mailing list. If you are on it, then I will give your name to other nearby users when they ask for the names of nearby users, and they are urged to contact you and update your copy. (I benefit by getting a better feel for how many distributions there have been, and having a better mailing list to use to give other users local people to contact). Use the registration form which can be accessed through our web site's registration page.

"How do I make a citation to the PHYLIP package in the paper I am writing?"

One way is like this:

Felsenstein, J. 2005. PHYLIP (Phylogeny Inference Package) version 3.6. Distributed by the author. Department of Genome Sciences, University of Washington, Seattle.

or if the editor for whom you are writing insists that the citation must be to a printed publication, you could cite a notice for version 3.2 published in Cladistics:

Felsenstein, J. 1989. PHYLIP - Phylogeny Inference Package (Version 3.2). Cladistics 5: 164-166.

For a while a printed version of the PHYLIP documentation was available and one could cite that. This is no longer true. Other than that, this is difficult, because I have never written a paper announcing PHYLIP! My 1985b paper in Evolution on the bootstrap method contains a one-paragraph Appendix describing the availability of this package, and that can also be cited as a reference for the package, although it was distributed since 1980 while the bootstrap paper is 1985. A paper on PHYLIP is needed mostly to give people something to cite, as word-of-mouth, references in other people's papers, and electronic newsgroup postings have spread the word about PHYLIP's existence quite effectively.

"Can I make copies of PHYLIP available to the students in my class?"

Generally, yes. Read the Copyright notice near the front of the main documentation page. If you charge money for PHYLIP, or use it in a service for which you charge money, you will need to negotiate a royalty. But you can make it freely available and you do not need to get any special permission from us to do so.

"How many copies of PHYLIP have been distributed?"

On 27 September, 1996 we reached 5,000 registered installations worldwide. (By now we are near 20,000 but have lost count for the moment because we have to make sure we don't count multiple registrations by the same person). Of course there are many more people who have got copies from friends. PHYLIP is probably the most widely distributed phylogeny package (figures for the others are not available). In recent years magnetic tape distribution and e-mail distribution of PHYLIP have disappeared, and so have diskette distributions (as I insist people use the network if they can). But all this has been more than offset by, first, an explosion of distributions by anonymous ftp over Internet, and then a bigger explosion of World Wide Web distributions and registrations (about 8 registrations per day at the moment).

Questions about documentation

"Where can I get a printed version of the PHYLIP documents?"

For the moment, you can only get a printed version by printing it yourself. For versions 3.1 to 3.3 a printed version was sold by Christopher Meacham and Tom Duncan, then at the University Herbarium of the University of California at Berkeley. But they have had to discontinue this as it was too much work. You should be able to print out the documentation files on almost any printer and make yourself a printed version of whichever of them you need.

"Why have I been dropped from your newsletter mailing list?"

You haven't. The newsletter was dropped. It simply was too hard to mail it out to such a large mailing list. The last issue of the newsletter was Number 9 in May, 1987. The Listserver News Bulletins that we tried for a while have also been dropped as too hard to keep up to date. I am hoping that our World Wide Web site will take their place.

Additional Frequently Asked Questions, or: "Why didn't it occur to you to ...

... allow the options to be set on the command line?"

We could in Unix and Linux, or somewhat differently in Windows. But there are so many options that this would be difficult, especially when the options require additional information to be supplied such as rates of evolution for many categories of sites. You may be asking this question because you want to automate the operation of PHYLIP programs using batch files (command files) to run in background. If that is the issue, see the section of this main documentation page on "Running the programs in background or under control of a command file". It explains how to set the options using input redirection and a file that has the menu responses as keystrokes.

... write these programs in Java?"

Well, we might. It is not completely clear which of two contenders, C++ and Java, will become more widespread, and which one will gradually fade away (at the moment there is no sign that either will fade away). If one becomes overwhelmingly more successful, we will probably want to use it for future versions of PHYLIP. As the C compilers that are used to compile PHYLIP are usually also able to compile C++, we will be moving in that direction, but with constant worrying about whether to convert PHYLIP to Java instead.

... forgot about all those inferior systems and just develop PHYLIP for Unix?"

This is self-answering, since the same people first said I should just develop it for Apple II's, then just for CP/M Z-80's, then just for IBM PCDOS, then just for Macintoshes or for Sun workstations, and then for Windows. If I had listened to them and done any one of these, I would have had a very hard time adapting the package to any of the other ones once these folks changed their mind (and most of them did)!

... write these programs in Pascal?"

These programs started out in Pascal in 1980. In 1993 we released both Pascal and C versions. Versions beyond 3.5, including revised versions of 3.5 were C-only. I make fewer mistakes in Pascal and do like the language better than C, but C has overtaken Pascal and Pascal compilers are starting to be hard to find. Also C is a bit better standardized which makes the number of modifications a user has to make to adapt the programs to their system much less.

... write these programs in PROLOG (or Ada, or Modula-2, or SIMULA, or BCPL, or PL/I, or APL, or LISP)?"

These are all languages I have considered. All have advantages, but they are not really widespread (as are C, C++, and Java).

... include in the package a program to do the Distance Wagner method, (or successive approximations character weighting)?"

In most cases where I have not included other methods, it is because I decided that they had no substantial advantages over methods that were included (such as the programs FITCH, KITSCH, NEIGHBOR, the T option of MIX and DOLLOP, and the "?" ancestral states option of the discrete characters parsimony programs).

... include in the package ordination methods and more clustering algorithms?"

Because this is not a clustering package, it's a package for phylogeny estimation. Those are different tasks with different objectives and mostly different methods. Mary Kuhner and Jon Yamato have, however, included in NEIGHBOR an option for UPGMA clustering, which will be very similar to KITSCH in results.

... include in the package a program to do nucleotide sequence alignment?"

Well, yes, I should have, and this is scheduled to be in future releases. But multiple sequence alignment programs, in the era after Sankoff, Morel, and Cedergren's 1973 classic paper, need to use substantial computer horsepower to estimate the alignment and the tree together (but see Karl Nicholas's program GeneDoc or Ward Wheeler and David Gladstein's MALIGN, as well as more approximate methods of tree-based alignment used in ClustalW, TreeAlign, or POY).

(Fortunately) obsolete questions

(The following four questions, once common, have finally disappeared, I am pleased to report).

"Why didn't it occur to you to ...

... let me log in to your computer in Seattle and copy the files out over a phone line?"

No thanks. It would cost you for a lot of long-distance telephone time, plus a half hour of my time and yours in which I had to explain to you how to log in and do the copying.

... send me a listing of your program?"

Damn it, it's not "a program", it's 35 programs, in a great many files. What were you thinking of doing, having 1800-line programs typed in by slaves at your end? If you were going to go to all that trouble why not try network transfer? If you have these then you can print out all the listings you want to and add them to the huge stack of printed output in the corner of your office.

... write a magnetic tape in our computer center's favorite format (inverted Lithuanian EBCDIC at 998 bpi)?"

Because the ANSI standard format is the most widely used one, and even though your computer center may pretend it can't read a tape written this way, if you sniff around you will find a utility to read it. It's just a lot easier for me to let you do that work. If I tried to put the tape into your format, I would probably get it wrong anyway.

... give us a version of these in FORTRAN?"

Because the programs are far easier to write and debug in C or Pascal, and cannot easily be rewritten into FORTRAN (they make extensive use of recursive calls and of records and pointers). In any case, C is widely available. If you don't have a C compiler or don't know how to use it, you are going to have to learn a language like C or Pascal sooner or later, and the sooner the better.

[Phylip icon here] ... to the PHYLIP home page