<commit_before># Introduction

*NetSPE* is a web-based software program for teaching rule-based phonology. It allows students to work out phonology-based puzzles and to interactively test analyses of data. It is designed to be relatively simple to use but powerful.

# Entering representations (URs and SRs)

Underlying and surface representations must be entered for each of the forms in an analysis. In puzzles, these will usually already be present. Representations are entered, one per line, in the boxes at the left of the window labelled URs and SRs. Typically, each line will start and end with the word boundary marker “#” (the legal kind of hash). Characters must be entered in Unicode representation or they will not be recognized. If they display properly in the box, they are in Unicode representation. Most tools that are available now for inputting phonetic characters are Unicode-based, so this typically is not a problem.

# Entering rules

Entering rules is somewhat more complicated. This is because the rule syntax is quite flexible and allows you to write many different types of rule. Once you learn the general conventions, you will be on your way toward writing you own rules.

## General conventions

### The structure of rules

All rules recognized by NetSPE have the structure:

    A -> B / X_Y

Where A describes the segment matched (the target), B describes how that segment is changed, and X and Y give the environment before and after the target. For example, one possible rule is:

    p -> pʰ / #_

This would state that /p/ becomes [pʰ] at the beginnings of words. A, or the target, must always consist of a single segment (diacritic modifiers are allowed).

The number “0” is used to represent the absence of a segment, and thus to write deletion rules. For example, a rule deleting /ŋ/ word-finally would have the form:

    ŋ -> 0 / _#
    
Word boundaries, as shown above, are indicated with the hash mark “#”, not with brackets.    

### Feature matrices

Most interesting rules cannot be stated without making reference to feature matrices. *NetSPE* has a notation for feature matrices that is simple and intuitive. A matrix containing +voice and -sonorant would be written as:

    [+voi, -son]

Feature matrices must be surronded by square brakets. Inside, each feature must be written with a specification (“+” or “-”). The features must be separated by commas. Spacing after commas is allowed but optional.

A rule stating that obstruents become devoiced word-finally would have the following form:

    [-son] -> [-voi] / _#

And a rule stating that stops become voiced after nasals could have the following form:

    [-cont, -son] -> [+voi] / [+nas, -syl]

### Aliases

For convenience, some classes can be represented in environments with single-character aliases:

* C [-syl]
* V [+syl]
* N [+nas, -syl]

## Feature names

Feature names are only useable in abbreviated form. This makes rules easier to type. The feature names and their definitions are given below:

* syl = syllabic
* son = sonorant
* cons = consonantal
* cont = continuant
* delrel = delayed release
* lat = lateral
* nas = nasal
* voi = voiced
* cg = constricted glottis
* sg = spread glottis
* ant = anterior
* lab = labial
* cor = coronal
* distr = distributed
* hi = high
* lo = low
* back = back
* round = round
* tense = tense
* long = long

## Alpha variables

Variables can be used in place of feature specifications (“+” or “-”). They are represented by the Greek letters alpha through zeta. They can be inserted by positioning the curson are the desired location and clicking one of the Greek letter buttons on the interface. *NetSPE* does *not* allow alpha variables with feature classes (like [place]).

# Reordering rules and representations

To reorder rules and representations (URs and SRs), simply double click on the header above the the box that you want to reorder. It will switch to reordering mode. You can then drag and drop items into the desired order. Double click the header in order to return to normal mode (which you must do before evaluating the derivation).

# Evaluation and interpretation of feedback

If you click the **evaluate** button, a derivation will be displayed. One the top row, the URs that you gave will be listed. On the bottom row, the SRs that you give will be listed. On the second to last row, the SRs computed from the derivation will be given. Between them are rows showing the application of each of the rules.

The object of the game, when using *NetSPE*, is to write and arrange the rules in such a way that the computed SRs and the given SRs are identical.<commit_msg>Added additional content to manual.txt<commit_after>Title: A Guide to Using NetSPE
Author: <NAME>
Date: 6 Nov 2011

# Introduction

*NetSPE* is a web-based software program for teaching rule-based phonology. It allows students to work out phonology-based puzzles and to interactively test analyses of data. It is designed to be relatively simple to use but powerful.

# Entering representations (URs and SRs)

Underlying and surface representations must be entered for each of the forms in an analysis. In puzzles, these will usually already be present. Representations are entered, one per line, in the boxes at the left of the window labelled **URs** and **SRs**. Typically, each line will start and end with the word boundary marker “#” (the legal kind of hash). Characters must be entered in Unicode representation or they will not be recognized. If they display properly in the box, they are in Unicode representation. Most tools that are available now for inputting phonetic characters are Unicode-based, so this typically is not a problem.

An optional gloss (translation) may be entered after each of the SRs. It should be separated from the SR by white space (e.g. a space) and should be enclosed in single quotes:

    #dɑg# 'canine'
    #kæt# 'feline'
    #hɔɹs# 'equine'

# Entering rules

Entering rules is somewhat more complicated. This is because the rule syntax is quite flexible and allows you to write many different types of rules. Once you learn the general conventions, you will be on your way toward writing you own rules.

## General conventions

### The structure of rules

All rules recognized by NetSPE have the structure:

    A -> B / X_Y

Where A describes the segment matched (the target), B describes how that segment is changed, and X and Y give the environment before and after the target. For example, one possible rule is:

    p -> pʰ / #_

This would state that /p/ becomes [pʰ] at the beginnings of words. A, or the target, must always consist of a single segment (diacritic modifiers are allowed).

The number “0” is used to represent the absence of a segment, and thus to write deletion rules. For example, a rule deleting /ŋ/ word-finally would have the form:

    ŋ -> 0 / _#
    
Word boundaries, as shown above, are indicated with the hash mark “#”, not with brackets.    

### Feature matrices

Most interesting rules cannot be stated without making reference to feature matrices. *NetSPE* has a notation for feature matrices that is simple and intuitive. A matrix containing +voice and -sonorant would be written as:

    [+voi, -son]

Feature matrices must be surronded by square brakets. Inside, each feature must be written with a specification (“+” or “-”). The features must be separated by commas. Spacing after commas is allowed but optional.

A rule stating that obstruents become devoiced word-finally would have the following form:

    [-son] -> [-voi] / _#

And a rule stating that stops become voiced after nasals could have the following form:

    [-cont, -son] -> [+voi] / [+nas, -syl]_

### Aliases

For convenience, some classes can be represented in environments with single-character aliases:

* C [-syl]
* V [+syl]
* N [+nas, -syl]

## Feature names

Feature names are only useable in abbreviated form. This makes rules easier to type. Case is significant; features must be entered in lowercase characters. The feature names and their definitions are given below:

* syl = syllabic
* son = sonorant
* cons = consonantal
* cont = continuant
* delrel = delayed release
* lat = lateral
* nas = nasal
* voi = voiced
* cg = constricted glottis
* sg = spread glottis
* ant = anterior
* lab = labial
* cor = coronal
* distr = distributed
* hi = high
* lo = low
* back = back
* round = round
* tense = tense
* long = long

## Alpha variables

Variables can be used in place of feature specifications (“+” or “-”). They are represented by the Greek letters alpha through zeta. They can be inserted by positioning the curson are the desired location and clicking one of the Greek letter buttons on the interface.

The following rule causes a consonant to assimilate in voicing to a preceding consonant:

    [-syll] -> [αvoi] / [αvoi]_

 *NetSPE* does *not* allow alpha variables with feature classes (like [place]).

## Disjunctions

Disjunctions (either X or Y or ...) are written between curly brackets—“{” and “}”—with the options separated by commas. A rule that devoices obstruents when they occur either at the end of a word or before another consonant can be written as follows:

    [-son] -> [-voi] / _{C, #}

## Quantification

Support for quantification in *NetSPE* is not yet complete. It does currently support a notation for matching option (zero or one of some group). This is done by enclosing the group in parentheses. A rule that says vowels become high when preceded by a vowel and zero or one consonants can be written as follows:

    [+syl] -> [+hi] / [+hi](C)_

# Reordering rules and representations

To reorder rules and representations (URs and SRs), simply double click on the header above the the box that you want to reorder. It will switch to reordering mode. You can then drag and drop items into the desired order. Double click the header in order to return to normal mode (which you must do before evaluating the derivation).

# Evaluation and interpretation of feedback

If you click the **evaluate** button, a derivation will be displayed. One the top row, the URs that you gave will be listed. On the bottom row, the SRs that you give will be listed. On the second to last row, the SRs computed from the derivation will be given. Between them are rows showing the application of each of the rules.

The object of the game, when using *NetSPE*, is to write and arrange the rules in such a way that the computed SRs and the given SRs are identical.
{'fraction_non_alphanumeric': 0.05962033768959268, 'fraction_numerical': 0.0008585328627301345, 'mean_word_length': 3.942951438000943, 'pattern_counts': {'":': 0, '<': 4, '<?xml version=': 0, '>': 17, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4060021', 'n_tokens_mistral': 2766, 'n_tokens_neox': 2634, 'n_words': 1630}