TTS: 200 som tekst blir ikkje generert i akkusativ #35
Comments
snomos
changed the title
|
slik som den regenerasjonsteg er nå det pröver å generere |
|
Ah - eg hadde missa at det ikkje var same ordklasse. Det er sjølvsagt ei anna historie. Før vi går vidare - @ilm024 kva er rett ordform i denne konteksten? Kva er det vi burde generera? Er det ei av desse formene? echo guoktatjuohte+Num+Sg+Acc | hfst-lookup -q tools/tts/generator-gt-norm.hfstol
guoktatjuohte+Num+Sg+Acc guoktjuodev 0.000000
guoktatjuohte+Num+Sg+Acc guoktatjuodev 0.000000
guoktatjuohte+Num+Sg+Acc guoktetjuodev 0.000000
guoktatjuohte+Num+Sg+Acc guovtetjuodev 0.000000? |
|
Når eg ser ein gong til på dette dømet, så er det likevel rett fram etter den algoritmen vi har lagt til grunn. Algoritmen er (kopiert frå dokumentet eg lenka til lenger opp):
I dømet med Av desse to analysene er den fyrste irrelevant, fordi ordklassen ikkje stemmer - vi har |
|
ja alså nå ble Num brukt som tagg för normalisering men om det var Arab og vi kan altid ta den bort det kan gå bra. |
|
Hm, vi kan ikkje bruka |
|
Då har eg endra |
|
Fiksa disambiguatoren slik at ikke Err/Orth blir valgt. Nå er resultatet slik (dvs. Gen siden jage også blir disambiguert til Gen): Kan jeg lukke buggen? |
|
No er disambigueringa i orden, men framleis er det problem med normaliseringa. Det som går inn til normaliseraren er dette, i genitiv, slik Linda seier (med kommandoen Men etter normaliseringa er det framleis nominativ, og vi har ei ekstra |
|
den har blitt lit komplisert så ä skrev ut alle versioner med full trace i dagens version: eller det er nesten densamme som: osv. |
|
So in the debug version it all looks good, except we could throw away some stuff, and we need to restrict the normaliser a bit, to not generate four variants of the same morphosyntactic form. I have commented the relevant parts below:
These forms are all good, but we need to restrict the normaliser so that it only generates the form we want (we need @ilm024 to decide which one). Alternatively, we generate all, but give them variant tags in the reanalysis, with enough information to select using CG in the next step. That way we can generate forms that fits with the rest of the text, given that there are clues in the rest of the text as to which version/style to pick. If we go this route, we still need to designate one variant as the default, probably tagged What I do not understand is why we end up with: ie So although everything is correct, we end up with the wrong form. That looks like a bug somewhere. The other forms, like |
|
Current version should throw away all tag strings that don't match (with ; in debug mode). |
|
Thanks, I just tested it. This is what I get: echo 'Dát máhtto de mak jåvsåj Finnmárko sámijda suláj 200 jage maŋŋela Kristusa riegádime.' \
| ./tools/tts/modes/trace-smj-normaliser.mode
"<200>"
"200" Num Arab Sg Gen "200>"MIDTAPE <W:0.0> SELECT:1388:Arab MAP:1357:>nNum @>N #9->10 SETPARENT:866:SetModToN
; "200" Num Arab Err/Orth Ess "200>"MIDTAPE <W:0.0> SELECT:1388:Arab REMOVE:4032:errsub
; "200" Num Arab Err/Orth Sg Acc "200>"MIDTAPE <W:0.0> SELECT:1388:Arab REMOVE:4032:errsub
; "200" Num Arab Err/Orth Sg Com "200>"MIDTAPE <W:0.0> SELECT:1388:Arab REMOVE:4032:errsub
; "200" Num Arab Sg Ela Attr "200"MIDTAPE <W:0.0> SELECT:1388:Arab IFF:3195
; "200" Num Arab Sg Ill Attr "200"MIDTAPE <W:0.0> SELECT:1388:Arab IFF:3195
; "200" Num Arab Sg Ine Attr "200"MIDTAPE <W:0.0> SELECT:1388:Arab IFF:3195
; "200" Num Arab Sg Nom "200>"MIDTAPE <W:0.0> SELECT:1388:Arab REMOVE:3397
; "200" Num Sem/ID "200"MIDTAPE <W:0.0> SELECT:1388:ArabSo no conversion anymore. I then run it on just echo 200 | hfst-tokenise -g tools/tts/tokeniser-tts-cggt-desc.pmhfst | \
egrep '(^"| Gen )' | \
divvun-normaliser -v -a tools/tts/analyser-gt-norm.hfstol \
-g tools/tts/generator-gt-norm.hfstol -n tools/tts/transcriptor-gt-desc.hfstol -t Arab
Being verbose.
Surface analyser set to: tools/tts/analyser-gt-norm.hfstol
Normaliser set to: tools/tts/transcriptor-gt-desc.hfstol
Generator set to: tools/tts/generator-gt-norm.hfstol
Deep analyser set to:
Tags set to: Arab
Reading files:
* tools/tts/transcriptor-gt-desc.hfstol
* tools/tts/generator-gt-norm.hfstol
* tools/tts/analyser-gt-norm.hfstol
*
expanding tags:
New surface form: 200
"<200>"
Expanding because of Arab
Using lemma: 200
1. looking up normaliser
2.a Using normalised form: guoktatjuodát
2.b regenerating lookup: guoktatjuodát+Num+Sg+Gen+MIDTAPE
3. Couldn't regenerate, reanalysing lemma: guoktatjuodát
; "guoktatjuodát" A Ord Attr "guoktatjuodát"phon "200"oldlemma NORMALISER_REMOVE:notgenerated
; "guoktatjuodát" A Ord Sg Nom "guoktatjuodát"phon "200"oldlemma NORMALISER_REMOVE:notgenerated
2.a Using normalised form: guoktatjuohte
2.b regenerating lookup: guoktatjuohte+Num+Sg+Gen+MIDTAPE
3. Couldn't regenerate, reanalysing lemma: guoktatjuohte
; "guoktatjuohte" Num Sg Nom "guoktatjuohte"phon "200"oldlemma NORMALISER_REMOVE:notgenerated
"200" Num Arab Sg Gen "200>"MIDTAPE <W:0.0>For whatever reason it is not able to generate. I then try the analysis and generation steps with the fst's used by the normaliser: echo guoktatjuohte | hfst-lookup -q tools/tts/analyser-gt-norm.hfstol
guoktatjuohte guoktatjuohte+Num+Sg+Nom 0.000000
echo guoktatjuohte+Num+Sg+Nom | hfst-lookup -q tools/tts/generator-gt-norm.hfstol
guoktatjuohte+Num+Sg+Nom guoktjuohte 0.000000
guoktatjuohte+Num+Sg+Nom guoktatjuohte 0.000000
guoktatjuohte+Num+Sg+Nom guoktetjuohte 0.000000
echo guoktatjuohte+Num+Sg+Gen | hfst-lookup -q tools/tts/generator-gt-norm.hfstol
guoktatjuohte+Num+Sg+Gen guoktjuode 0.000000
guoktatjuohte+Num+Sg+Gen guoktatjuode 0.000000
guoktatjuohte+Num+Sg+Gen guoktetjuode 0.000000
guoktatjuohte+Num+Sg+Gen guovtetjuode 0.000000No problems whatsoever. So the question is: why can't the generator generate when used in the normaliser, when there is no problems when used directly on the command line? |
|
Det kan sjå ut som om |
|
Om det er det så vil det forklara kvifor genereringa ikkje går gjennom 🙂 |
|
ah ja det er sant men det går litt på den tema vi snakke siste uke at det er forskjellige cg-parsers alla steder i kodebase, denne var ikke särleg flink med tagtolkingar. |
|
Ok. Vi burde kanskje ha berre ein kodebase for å parsa CG, ev bruka kode frå VislCG3-koden? |
|
Fixed in divvun/libdivvun@d0647bf: echo 'Dát máhtto de mak jåvsåj Finnmárko sámijda suláj 200 jage maŋŋela Kristusa riegádime.' | \
./tools/tts/modes/trace-smj-normaliser.mode
...
"<200>"
"guoktatjuohte" Num Sg Gen "guoktjuode"phon "200"oldlemma
"guoktatjuohte" Num Sg Gen "guoktatjuode"phon "200"oldlemma
"guoktatjuohte" Num Sg Gen "guoktetjuode"phon "200"oldlemma
"guoktatjuohte" Num Sg Gen "guovtetjuode"phon "200"oldlemma
; "200" Num Arab Err/Orth Ess "200>"MIDTAPE <W:0.0> SELECT:1388:Arab REMOVE:4032:errsub
; "200" Num Arab Err/Orth Sg Acc "200>"MIDTAPE <W:0.0> SELECT:1388:Arab REMOVE:4032:errsub
; "200" Num Arab Err/Orth Sg Com "200>"MIDTAPE <W:0.0> SELECT:1388:Arab REMOVE:4032:errsub
; "200" Num Arab Sg Ela Attr "200"MIDTAPE <W:0.0> SELECT:1388:Arab IFF:3195
; "200" Num Arab Sg Ill Attr "200"MIDTAPE <W:0.0> SELECT:1388:Arab IFF:3195
; "200" Num Arab Sg Ine Attr "200"MIDTAPE <W:0.0> SELECT:1388:Arab IFF:3195
; "200" Num Arab Sg Nom "200>"MIDTAPE <W:0.0> SELECT:1388:Arab REMOVE:3397
; "200" Num Sem/ID "200"MIDTAPE <W:0.0> SELECT:1388:ArabGreat! We can move on to the next bug 🙂 |
|
Vi skal ha Gen som "guoktatjuode". Guoktjuode går ikke, da det ikke er en sammensetningsdel foran. Dette er på min "to do" liste", men jeg trenger hjelp, da jeg ikke får det til selv. "Guokte" er allerede tagget med Use/Marg,kan man ikke styre unna disee automatisk? |
|
Ja, det skal skje automatisk. Det krevst litt omorganisering, men det skal bli ordna. |
|
No skjer det automatisk basert på taggane du har lagt inn, @ilm024 🙂 echo 'Dát máhtto de mak jåvsåj Finnmárko sámijda suláj 200 jage maŋŋela Kristusa riegádime.' | \
./tools/tts/modes/trace-smj-normaliser.mode
...
"<sámijda>"
"sábme" N Sem/Hum_Lang Pl Ill "sábme>Q1jda"MIDTAPE <W:0.0> @<ADVL #7->5
:
"<suláj>"
"sulla" N Sem/Dummytag Pl Com "sulla>Q1j"MIDTAPE <W:0.0> @<ADVL #8->5
:
"<200>"
"guoktatjuodát" A Ord Attr "guoktatjuodát"phon "200"oldlemma
"guoktatjuodát" A Ord Sg Nom "guoktatjuodát"phon "200"oldlemma
"guoktatjuohte" Num Sg Gen "guoktatjuode"phon "200"oldlemma
:
"<jage>"
"jahke" N Sem/Time Sg Gen "jahke>Q1"MIDTAPE <W:0.0> @<ADVL #10->5
:
"<maŋŋela>"
"maŋŋel" N Sem/Dummytag Sg Gen "maŋŋela"MIDTAPE <W:0.0> @>N #11->12@flammie når det gjeld ordenstalsforma som dukkar opp, så ser det ut som eit steg tilbake (ein regresjon) - du hadde jo løyst det problemet tidlegare? Dvs ignorer genererte former som ikkje stemmer i POS med den ordklassa vi sender inn, stemmer ikkje det? Så kva skjer her? |
|
tror dem var kasta bort för pga genereringsfeil, som fiks til #36 så bruker vi lemmaform fra transcriptor uansett. Kanskje ä kan bare matcha taggenne med denne form også... |
|
Etter at eg fekk testa med nyaste bygg av echo 'Dát máhtto de mak jåvsåj Finnmárko sámijda suláj 200 jage maŋŋela Kristusa riegádime.' | \
./tools/tts/modes/smj-normaliser.mode
[...]
"<suláj>"
"sulla" N Sem/Dummytag Pl Com "sulla>Q1j"MIDTAPE <W:0.0> @<ADVL #8->5
:
"<200>"
"guoktatjuohte" Num Sg Gen "guoktatjuode"phon "200"oldlemma
:
"<jage>"
"jahke" N Sem/Time Sg Gen "jahke>Q1"MIDTAPE <W:0.0> @<ADVL #10->5
:
"<maŋŋela>"
"maŋŋel" N Sem/Dummytag Sg Gen "maŋŋela"MIDTAPE <W:0.0> @>N #11->12Ingen fleire fleirtydige former, berre den vi vil ha 😄 |
I denne setninga:
blir 200 disambiguert til akkusativ:
Men den genererte ordforma er ikkje i akkusativ, ho er i nominativ i
phon-elementet:Akkusativ er:
Slik det er skildra her er tanken at vi som siste steg i normaliseringa generer rett form basert på taggane i originalordet. Gjer vi det, eller er det andre problem?
The text was updated successfully, but these errors were encountered: