Difference between revisions of "Ideas for Google Summer of Code/More robust recursive transfer"
Jump to navigation
Jump to search
(Created page with "{{TOCD}} Currently, one has to be very careful in writing recursive transfer rules to ensure they don't get too deep or ambiguous, and that they cover full sentences. See in...") |
|||
(One intermediate revision by the same user not shown) | |||
Line 2: | Line 2: | ||
Currently, one has to be very careful in writing recursive transfer rules to ensure they don't get too deep or ambiguous, and that they cover full sentences. See in particular issues [https://github.com/apertium/apertium-recursive/issues/97 97] and [https://github.com/apertium/apertium-recursive/issues/80 80]. We would like linguists to be able to fearlessly write recursive (rtx) rules based on what makes linguistic sense, and have rtx-proc/rtx-comp deal with the computational/performance side. |
Currently, one has to be very careful in writing recursive transfer rules to ensure they don't get too deep or ambiguous, and that they cover full sentences. See in particular issues [https://github.com/apertium/apertium-recursive/issues/97 97] and [https://github.com/apertium/apertium-recursive/issues/80 80]. We would like linguists to be able to fearlessly write recursive (rtx) rules based on what makes linguistic sense, and have rtx-proc/rtx-comp deal with the computational/performance side. |
||
+ | |||
==Tasks== |
==Tasks== |
||
+ | * There has been lots of research on parsing. Document relevant methods that might help solve the issues. |
||
+ | * Implement solutions to the parse performance issues in the apertium-recursive code-base |
||
+ | * If there is time, solve other [https://github.com/apertium/apertium-recursive/issues/ open issues] |
||
==Coding challenge== |
==Coding challenge== |
||
− | + | * Install Apertium (see [[Minimal installation from SVN]]) |
|
− | + | * Compile apertium-recursive from source |
|
+ | |||
− | # ??? |
||
+ | then |
||
+ | |||
+ | * write a short grammar for a language you know that doesn't have one yet, to get to know the formalism |
||
+ | |||
+ | or |
||
+ | |||
+ | * Add a compiler warning, e.g. https://github.com/apertium/apertium-recursive/issues/89 https://github.com/apertium/apertium-recursive/issues/78 |
||
==Frequently asked questions== |
==Frequently asked questions== |
Latest revision as of 09:22, 6 February 2024
Currently, one has to be very careful in writing recursive transfer rules to ensure they don't get too deep or ambiguous, and that they cover full sentences. See in particular issues 97 and 80. We would like linguists to be able to fearlessly write recursive (rtx) rules based on what makes linguistic sense, and have rtx-proc/rtx-comp deal with the computational/performance side.
Tasks[edit]
- There has been lots of research on parsing. Document relevant methods that might help solve the issues.
- Implement solutions to the parse performance issues in the apertium-recursive code-base
- If there is time, solve other open issues
Coding challenge[edit]
- Install Apertium (see Minimal installation from SVN)
- Compile apertium-recursive from source
then
- write a short grammar for a language you know that doesn't have one yet, to get to know the formalism
or
- Add a compiler warning, e.g. https://github.com/apertium/apertium-recursive/issues/89 https://github.com/apertium/apertium-recursive/issues/78
Frequently asked questions[edit]
- none yet, ask us something! :)
See also[edit]
- Ideas_for_Google_Summer_of_Code/Robust_recursive_transfer The first GsoC recursive transfer project