Morphological generator - Revision history

Jwashin1: /* Multiple correct forms */

2026-03-25T17:42:21Z

‎Multiple correct forms

Jwashin1: /* Initial evaluation */

2026-03-02T19:21:12Z

‎Initial evaluation

Jwashin1: /* Final evaluation */

2026-03-02T19:20:55Z

‎Final evaluation

Jwashin1: /* The assignment */

2026-03-02T19:20:01Z

‎The assignment

Jwashin1: /* The hard stuff */

2025-05-30T14:54:22Z

‎The hard stuff

Jwashin1: /* The assignment */

2025-03-04T16:10:33Z

‎The assignment

Jwashin1: /* The basics */

2024-01-28T18:07:31Z

‎The basics

Jwashin1: /* Initial evaluation */

2023-02-27T18:37:05Z

‎Initial evaluation

Jwashin1: /* Multiple correct forms */

2023-02-27T18:23:56Z

‎Multiple correct forms

Jwashin1: /* Common pitfalls */

2022-03-22T18:02:32Z

‎Common pitfalls

@@ Line 101: / Line 101: @@
 Sometimes there are multiple correct forms for a given analysis in a language.  In cases like this, you should analyse all of them, but only generate one.  You can use <code>Dir/LR</code> in the comment section of a form to allow only form-to-analysis mapping (and not analysis-to-form mapping).  You may also want to add both forms to your tests file.
-An example of this is the English word "dwarf", the plural of which can be "dwarves" or "dwarfs".  Since the former is considered correct by more people (or simply, is more commonly used), we'll consider it correct.  You'll want something like this in your <code>lexd</code> file:
+An example of this is the English word "scarf", which has the permissible plural forms "scarves" or "scarfs".  Since the former is considered correct by more people (or simply, is more commonly used), we'll consider it "correct", or at least "preferred".  You'll want something like this in your <code>lexd</code> file:
 <pre>
-dwarf:dwar{F}  #
+scarf:scar{F}  #
-dwarf:dwarf    # Dir/LR
+scarf:scarf    # Dir/LR
 </pre>

@@ Line 195: / Line 195: @@
 # Make a section on your Transducer wiki page for '''generator evaluation''' with a subsection title something like "initial evaluation of morphological generation" and note the number of '''passing and failing morphological analysis tests''' at this point using the morphology test method used for your analyser assignment.
 #* Put existing sections under a new "Analyser evaluation" section to keep it separate from the generator evaluation.
-# Also rerun the '''coverage test on your corpus''', and add the current coverage number.
+# Also rerun the '''coverage test on your largest corpus''', and add the current coverage number.
 # Run your generation tests using <code>apertium-regtest test -c .-gen</code>.  Put the '''number of gold matches for the generation test''' in the same subsection on the wiki page.

@@ Line 216: / Line 216: @@
 ** to compare all your work: <code>git diff analyser</code>
 ** to compare only a given file (e.g., your twol file): <code>git diff analyser apertium-xyz.xyz.twol</code>
-* Again run the '''coverage test on your corpus''', and add the new coverage number.
+* Again run the '''coverage test on your largest corpus''', and add the new coverage number.
 == Additional resources ==

@@ Line 186: / Line 186: @@
 == The assignment ==
-This assignment will be due at the end of the week during the 6th week (this semester: '''23:59 on Friday, March 7th, 2025''').
+This assignment will be due at the end of the week during the 6th week (this semester: '''23:59 on Friday, March 6th, 2026''').
 === Initial evaluation ===
@@ Line 202: / Line 202: @@
 <!-- * Note that if every test passes analysis but has multiple forms generated, then exactly one-half of your generation tests will pass—this is simply due to the way the tests are counted (i.e., each form will be counted as both passing and failing).  In such a situation, each form which subsequently is made to have only a correct form generated will reduce the number of failing tests by one, but not increase the number of passing tests.  Hence, if all your tests analyse correctly, then you only need to write twol rules to make half of them generate correctly.
 * In another situation, half (or a little more) of your tests might be passing, and these same tests might generate correctly because you don't have any need for twol rules.  If you do not need '''at least one twol rule''' (verify this with me!), then you should do extra work on your lexd file so that '''at least 85%''' of your tests pass. -->
-* If you already had some necessary twol rules implemented and didn't need to modify even one of them for this part of the assignment, then you only need to aim for '''75% of generation tests matching gold'''.
+<!--
 Also note:

@@ Line 199: / Line 199: @@
 === The hard stuff ===
-Continue development of your transducer, focussing on twol rules, so that '''two-thirds''' of your [minimum 50] tests pass.
+Continue development of your transducer, focussing on twol rules, so that '''two-thirds''' of your [minimum 50] tests match gold.
-* Note that if every test passes analysis but has multiple forms generated, then exactly one-half of your generation tests will pass—this is simply due to the way the tests are counted (i.e., each form will be counted as both passing and failing).  In such a situation, each form which subsequently is made to have only a correct form generated will reduce the number of failing tests by one, but not increase the number of passing tests.  Hence, if all your tests analyse correctly, then you only need to write twol rules to make half of them generate correctly.
+<!-- * Note that if every test passes analysis but has multiple forms generated, then exactly one-half of your generation tests will pass—this is simply due to the way the tests are counted (i.e., each form will be counted as both passing and failing).  In such a situation, each form which subsequently is made to have only a correct form generated will reduce the number of failing tests by one, but not increase the number of passing tests.  Hence, if all your tests analyse correctly, then you only need to write twol rules to make half of them generate correctly.
-* In another situation, half (or a little more) of your tests might be passing, and these same tests might generate correctly because you don't have any need for twol rules.  If you do not need '''at least one twol rule''' (verify this with me!), then you should do extra work on your lexd file so that '''at least 85%''' of your tests pass.
+* In another situation, half (or a little more) of your tests might be passing, and these same tests might generate correctly because you don't have any need for twol rules.  If you do not need '''at least one twol rule''' (verify this with me!), then you should do extra work on your lexd file so that '''at least 85%''' of your tests pass. -->
-* If you already had some necessary twol rules implemented and didn't need to modify even one of them for this part of the assignment, then you only need to aim for '''75% passing generation tests'''.
+* If you already had some necessary twol rules implemented and didn't need to modify even one of them for this part of the assignment, then you only need to aim for '''75% of generation tests matching gold'''.
 Also note:

@@ Line 1: / Line 1: @@
 == The basics ==
-<code>Twol</code> (pronounced [tuˈɛl]) constraints (or rules) are written to limit (or change) the output of the <code>lexd</code> level of the transducer on a character-by-character basis.  One way of thinking of it is that the rules map between the morphological or phonological level and the phonetic or orthographical level.  It's less useful to think of the rules as "transforming" the input—this approach is slightly inaccurate and can lead to problems.
+<code>Twol</code> (pronounced [tuˈɛl]) constraints (or rules) are written to limit (or change) the output (form, or "surface" form—not analysis side) of the <code>lexd</code> level of the transducer on a character-by-character basis.  One way of thinking of it is that the rules map between the morphological or phonological level and the phonetic or orthographical level.  It's less useful to think of the rules as "transforming" the input—this approach is slightly inaccurate and can lead to problems.
 A <code>twol</code> rule is structured around an environment where a <code>lexd</code>-level symbol (or symbols) are restricted to a particular orthographic form-level symbol.

@@ Line 107: / Line 107: @@
 </pre>
-If you want to have both output forms in your yaml tests file (good for analysis tests, not for generation tests), you can have an entry like the following:
+If you want to have both output forms in your test file (good for analysis tests, not for generation tests), you can simply have two entries in your <code>-morph-input.txt</code> file.  See [[Apertium-regtest#Manually adding tests]] for more info about adding tests manually.
 === Common pitfalls ===

@@ Line 117: / Line 117: @@
 <!-- * Make sure all your multi-character symbols are also listed in the <code>Multichar_Symbols</code> section of the lexd file. -->
 * Make sure there's at least one set in the Sets section, and at least one rule in the Rules section (even if they do nothing).
-* Make sure you put spaces around but not within symbol pairs.  Also make sure you have spaces adjacent to brackets correct.  Spaces are very important in <code>twol</code>!
+* Make sure you put '''spaces''' around but not within symbol pairs.  Also make sure you have spaces adjacent to brackets correct.  Spaces are very important in <code>twol</code>!
 == Useful commands ==