Apertium-recursive - Revision history

Trondtr at 06:13, 1 June 2023

2023-06-01T06:13:19Z

Popcorndude: /* Chunk syntax */

2021-05-05T14:26:51Z

Chunk syntax

Popcorndude: try to fix invalid html issue

2021-05-05T14:25:42Z

try to fix invalid html issue

Popcorndude: /* Differences From .tx /

2021-02-18T14:28:23Z

Differences From .t*x

Popcorndude: /* Makefile.am */

2021-02-18T14:19:47Z

Makefile.am

Popcorndude: /* configure.ac */

2021-02-18T14:17:28Z

configure.ac

Popcorndude: /* Incorporating Into a Pair */

2021-02-18T14:16:48Z

Incorporating Into a Pair

Popcorndude: /* Lexicalized Weights */ mention default weight

2020-01-12T20:14:06Z

Lexicalized Weights: mention default weight

Popcorndude: /* Incorporating Into a Pair */ mention apertium-init

2019-11-25T20:41:49Z

Incorporating Into a Pair: mention apertium-init

Firespeaker: /* See Also */

2019-10-17T17:46:39Z

← Older revision		Revision as of 06:13, 1 June 2023
Line 149:		Line 149:

	[[Category:Transfer]]		[[Category:Transfer]]
			[[Category:Recursive transfer\|*]]

@@ Line 72: / Line 72: @@
  <chunk>
-   <source> [lemma] [tags] </source>
+   &lt;source&gt; [lemma] [tags] &lt;/source&gt;
    <target> [lemma] [tags] </target>
    <reference> [lemma] [tags] </reference>

@@ Line 78: / Line 78: @@
  </chunk>
-<code><source></code> and <code><reference></code> are optional and can be used to pass extra information to subsequent rules (which can access them with <code><clip side="sl" .../></code> as usual).
+<code>&lt;source&gt;</code> and <code>&lt;reference&gt;</code> are optional and can be used to pass extra information to subsequent rules (which can access them with <code>&lt;clip side="sl" .../&gt;</code> as usual).
 === Postchunk rules ===
-Rather than being conditioned on chunk names, output-time (postchunk-like) rules are written in <code><output-action></code> blocks following the <code><action></code> blocks in the rules they correspond to.
+Rather than being conditioned on chunk names, output-time (postchunk-like) rules are written in <code>&lt;output-action&gt;</code> blocks following the <code>&lt;action&gt;</code> blocks in the rules they correspond to.
 The following aspects of standard transfer files are unsupported or have potentially unpredictable results and should be avoided:
@@ Line 88: / Line 88: @@
 === Chunks With the Same Tags as LUs ===
-A number of pairs have rules that match punctuation and reset variables. Unfortunately, these rules often produce chunks with the same part of speech tag (e.g. match <code><sent></code> and output <code><sent></code>), which can lead to infinite recursion since the rule can match its own output.
+A number of pairs have rules that match punctuation and reset variables. Unfortunately, these rules often produce chunks with the same part of speech tag (e.g. match <code>&lt;sent&gt;</code> and output <code>&lt;sent&gt;</code>), which can lead to infinite recursion since the rule can match its own output.
 With <code>trx-comp</code> this is possible but should be avoided.

@@ Line 67: / Line 67: @@
 If <code>firstChunk</code> is not specified, the rule will be treated as if it can generate any chunk, which may lead to significant slowdowns in <code>rtx-proc</code>.
+=== Chunk syntax ===
-The following aspects of standard transfer files are unsupported or have potentially unpredictable results and should be avoided:
-=== Chunks With the Same Tags as LUs ===
+Chunks have the following structure:
+ <chunk>
-A number of pairs have rules that match punctuation and reset variables. Unfortunately, these rules often produce chunks with the same part of speech tag (e.g. match <code><sent></code> and output <code><sent></code>), which can lead to infinite recursion since the rule can match its own output.
+   <source> [lemma] [tags] </source>
+   <target> [lemma] [tags] </target>
+   <reference> [lemma] [tags] </reference>
+   <contents> [chunks, LUs, and blanks] </contents>
+ </chunk>
+<code><source></code> and <code><reference></code> are optional and can be used to pass extra information to subsequent rules (which can access them with <code><clip side="sl" .../></code> as usual).
-With <code>trx-comp</code> this is possible but should be avoided.
-=== Literal Chunks ===
+=== Postchunk rules ===
+Rather than being conditioned on chunk names, output-time (postchunk-like) rules are written in <code><output-action></code> blocks following the <code><action></code> blocks in the rules they correspond to.
-In interchunk, new chunks are sometimes inserted like this:
+The following aspects of standard transfer files are unsupported or have potentially unpredictable results and should be avoided:
- <chunk>
-  <lit v="det"/>
-  <lit-tag v="DET.def"/>
-  <lit v="{^the"/>
-  <lit-tag v="det.def.mf.sp"/>
-  <lit v="$}"/>
- </chunk>
+=== Chunks With the Same Tags as LUs ===
-<code>trx-comp</code> will make some effort to deal with this, but results are not guaranteed and the curly braces may show up in the output. Instead write the above as:
+A number of pairs have rules that match punctuation and reset variables. Unfortunately, these rules often produce chunks with the same part of speech tag (e.g. match <code><sent></code> and output <code><sent></code>), which can lead to infinite recursion since the rule can match its own output.
- <chunk name="det">
-  <tags>
+With <code>trx-comp</code> this is possible but should be avoided.
-   <tag><lit-tag v="DET"/></tag>
-   <tag><lit-tag v="def"/></tag>
-  </tags>
-  <lit v="the"/>
-  <lit-tag v="det.def.mf.sp"/>
- </chunk>
-or even
- <lu>
-  <lit v="the"/>
-  <lit-tag v="det.def.mf.sp"/>
- </lu>
-depending on what you're doing with it. (Note that <code>trx-comp</code> doesn't check the syntactic distinctions between .t1x and .t2x files.)
 === Chunks Not Containing Blanks ===

@@ Line 18: / Line 18: @@
 Add <code>$(PREFIX1).rtx.bin</code> and <code>$(PREFIX2).rtx.bin</code> to <code>TARGETS_COMMON</code>.
+If you have the latest version of Apertium installed, the following recipes will be included by <code>@ap_include@</code> and you don't need to add them.
  $(PREFIX1).rtx.bin: $(BASENAME).$(PREFIX1).rtx

@@ Line 49: / Line 49: @@
 === configure.ac ===
+ PKG_CHECK_MODULES(APERTIUM_RECURSIVE, apertium-recursive >= 1.0.0)
- AC_PATH_PROG([RTXCOMP], [rtx-comp], [false], [$PATH$PATH_SEPARATOR$with_rtx_comp/bin])
- AS_IF([test x$RTXCOMP = xfalse], [AC_MSG_ERROR([You don't have rtx-comp installed])])
- AC_PATH_PROG([RTXPROC], [rtx-proc], [false], [$PATH$PATH_SEPARATOR$with_rtx_proc/bin])
- AS_IF([test x$RTXPROC = xfalse], [AC_MSG_ERROR([You don't have rtx-proc installed])])
 == Differences From .t*x ==

@@ Line 11: / Line 11: @@
 == Incorporating Into a Pair ==
-The following instructions are for the Yacc-like syntax. To use XML, replace references to <code>rtx-comp</code> with <code>trx-comp</code>.
+The following applies regardless of whether the YACC-derived syntax or the XML is used.
 Note that all of these changes can be made automatically with the <code>--rebuild</code> option of [[Apertium-init]].

@@ Line 125: / Line 125: @@
  ...
-Where the three columns are separated by tabs, the rule name matches one of the rules in the <code>.rtx</code> file or the <code>id</code> attribute of one of the rules in the XML file, the weight is a positive floating point number, and the pattern is the same length as the pattern of the corresponding rule.
+Where the three columns are separated by tabs, the rule name matches one of the rules in the <code>.rtx</code> file or the <code>id</code> attribute of one of the rules in the XML file, the weight is a positive floating point number, and the pattern is the same length as the pattern of the corresponding rule. Higher weights are preferred and the default weight is 0.
-The patterns are of the form "lemma@tags lemma@tags ..." where the terms are separated by spaces and the syntax of the components follows the same rules as elsewhere, that is "ba*@n.*" will match "bag<n><m><sg>" and "bagel<n>". (Note that <code>rtx-comp</code> allows <code>*</code> to 0 tags).
+The patterns are of the form "lemma@tags lemma@tags ..." where the terms are separated by spaces and the syntax of the components follows the same rules as elsewhere, that is "ba*@n.*" will match "bag<n><m><sg>" and "bagel<n>". (Note that <code>rtx-comp</code> allows <code>*</code> to match 0 tags).
 Note that the patterns given are added to the transducer unmodified, so if they are less specific than the original rules, the results may be incorrect.

@@ Line 148: / Line 148: @@
  of	1.0	constitución@n.* de@pr 1812@n.*
-== See Also ==
+== Further Documentation ==
 * [[Apertium-recursive/Formalism]] Rule-file format
@@ Line 155: / Line 155: @@
 * [[Apertium-recursive/Example]] Example of the parser in action
 * [[Apertium-recursive/Bytecode]] Documentation of binary file format
+== See Also ==
 * [[User:Popcorndude/Recursive_Transfer]] GSoC 2019 project proposal