Support data and programs for the article "Epic Rhythm: Metrical Shapes in Greek Hexameter" Greek, Roman, and Byzantine Studies 64.3 (2024), 350–77.
The Online Appendix can be found here. Other source code and data are at the support page.
The source data for analysis are the preprocessed corpus CSV files in the corpus directory. They come from the sedes repository at commit 2ec2a1240e75acec2588838f18e18220ecced9f1. To recreate the source files:
$ cd sedes/
$ git checkout 2ec2a1240e75acec2588838f18e18220ecced9f1
$ (source venv/bin/activate && make clean && make -j4)
Then copy sedes/corpus/*.csv into the corpus directory here.
Processing the source data requires some programs from the sedes repository.
Set the $SEDES environment variable to the path to a
clone of the sedes repository.
It may be a relative path.
For example, if epic-rhythm is cloned next to sedes,
SEDES=../sedes/
Then run
make
Alternatively, you can provide the $SEDES path on the make command line,
rather than setting it as an environment variable:
make SEDES=../sedes/
Running make will produce the following output files:
- corpus-appositive/*.csv: Corpus CSV files, but where the
wordcolumn represents appositive groups, rather than single words. - expectancy.sedes-work,metrical_shape.csv: Expectancy of sedes by work and metrical shape, in the complete appositive-group corpus.
- expectancy.sedes-metrical_shape.archaic.csv: Expectancy of sedes by metrical shape, in the Archaic corpus (iliad, odyssey, homerichymns, theogony, worksanddays, shield).
- expectancy.sedes-metrical_shape.archaic+hellenistic.csv: Expectancy of sedes by metrical shape, in the Archaic and Hellenistic corpus (Archaic plus argonautica, callimachushymns, aratus, theocritus).
- expectancy.sedes-metrical_shape.csv: Expectancy of sedes by metrical shape, in the complete appositive-group corpus (Archaic and Hellenistic plus quintussmyrnaeus, nonnusdionysiaca).
- joined.sedes-metrical_shape.csv: Appositive-group corpus joined with expectancy of sedes by metrical shape.
- tables.html: HTML tables of sedes expectancy by work, with one table for each metrical shape.
- summary-ssl.html: HTML table of sedes expectancy by work, for the metrical shape ⏑⏑– only (except from tables.html).
- summary-table.html: HTML table of sedes expectancy by metrical shape, over the complete appositive-group corpus.
- unexpected-table.html: HTML table of numbers and rates of unexpected metrical shapes per work, and the books with the highest and lowest rates.
- unexpected.txt: Various one-off calculations of rates of unexpected metrical shapes.
- Hom.Hymn.4-windows.png: Graph of unexpected shapes per window in Hom.Hymn 4.
The word "ἀμφ’" in ALWAYS_PREPOSITIVE_WORDS was erroneously specified as "μφ᾽",
with U+1FBD GREEK KORONIS in place of the U+2019 RIGHT SINGLE QUOTATION MARK,
which prevented the word from being marked as prepositive as intended.
This would have changed about 200 appositive groups across the corpus.
There are other words that might have been marked as prepositive or postpositive, but were not, in Epic Rhythm. Later additions to the word lists appear in the SEDES program:
- https://github.com/sasansom/sedes/commit/763ca754c70ee05921dfc357768c022623e2c5e0
- https://github.com/sasansom/sedes/commit/570cda9577bd553b313bbaafbffd57d63c505613
- https://github.com/sasansom/sedes/commit/535dd84f0fd5babcc4487fff32d2e98b470e9768
The HTML tables are meant to be copied and pasted into a word processor. They include non-breaking space characters where text in a cell should not line-break. But both Firefox and Chrome fail to preserve non-breaking spaces when copying selected text in the browser window. So you may have to patch up bad line breaks manually.
In Firefox, the issue is discussed in:
- 359303 - Non-breaking spaces (nbsp) not copied as such (closed but without fixing the problem)
- 1769534 - Preserve non-breaking spaces when copying HTML content (open as of 2024-01-01)
Chromium issue 887511 seems to suggest that Chrome retains non-breaking spaces, but it does not work for me in Chromium 120.0.6099.129. A Stack Overflow post says there is a "well-known bug in both Gecko (Firefox) and Blink (Google Chrome)."