New element type with repetition causing slow recognition in DNS

[Jason Veldicott]

Baffled as to what is going wrong, as recognition works in simulation, just not when speaking through DNS.  This may suggest the problem is in how the new element is compiled for DNS.  But then the element does work okay without repetition (and only single utterance).

This newly defined element recognises simply:  word | "caps" word, where word may be a single letter:

MyElement(ElementBase):

    def decode(self, state):

        state.decode_attempt(self)

        word = state.word()

        if word is None or (word=="stop"):

            state.decode_failure(self) 

            return

        if len(word)==1:

            self._char += word.lower()

            state.next(1)

        else:

            if word=="caps":

                word=state.word(1)                      

                self._char += str(word[0]).capitalize()                

                state.next(2)

            else:

                self._char += str(word[0]).lower()

                state.next(1)

        state.decode_success(self) 

        yield state

        state.decode_failure(self)     

        return

As far as I know, the necessary calls - decode_attempt, next, decode_success, decode_failure - have been included as required.  There is also decode_retry and decode_rollback, whose purpose it not fully understood, but my hunch is, in this case, they're not required.

The compiler part for this element (in dragonfly.engines.compiler_natlink, or dragonfly.engines.backend_natlink.compiler in Dragonfly v0.6.6b1), which I've borrowed directly from that for Dictation:

    def _compile_myelement(self, element, compiler):

        compiler.add_rule("dgndictation", imported=True)

The grammar:

class TestRule(CompoundRule):

    exported = True

    spec = "word1<myelement>|word2<myelementREP>stop"

    extras =  [

               MyElement(name="myelement"),

                Repetition(MyElement(), min=1, max=20, name="myelementREP")

               ]

ruleRef = RuleRef(TestRule())

(and this is the element of an enclosing rule)

If anyone has any ideas as to why this code is getting stuck in DNS, I'd greatly appreciate any comments, as I'm not hugely familiar as yet with the parsing and compilation elements of Dragonfly.  

Am using Dragonfly v0.6.6b1, which is more recent than the official release version available from the Dragonfly website (v0.6.5), but am assuming that the problem is more likely due to my code above rather than any bugs in the beta.

Thanks

Jason

[Charlie Tango]

Hello Jason,

I copied your code above into a command module, added the boilerplate
to load it, and played around with it. For me everything seems to
work, although I'm not sure what you would like to happen here. So, in
other words I cannot reproduce your slow recognitions or recognitions
not happening. But, I'm not sure what I should be looking for...

Could you please explain what you are trying to achieve here? Perhaps
several usage examples (say this, get that result) would help me
understand your purpose.

Note that it appears that you are mixing the decoding of recognition
results with formatting of dictated text. I'm not sure that is the
best way to do custom processing of "in-line" formatting specifiers
such as "caps". I'd recommend instead to leave the Dictation element's
decode() method as is, and instead supply a custom dictation formatter
(instead of the standard
dragonfly.engines.backend_natlink.NatlinkDictationContainer).

Best regards,
Charlie

PS: You state a difference in behavior between actual use (human
speaking) and "simulation". How do you do such simulation?

[Jason Veldicott]

My apologies, I assumed there was an absence of interest in this topic, so did not get around to posting an update on it.

You're right, the code does work.  Perhaps it wasn't for me initially due to runs of buggy element code disrupting normal DNS function.  I tried it the following day, and to my great delight it worked problem free.  No doubt it will serve as something of an example of how an element may be added, should others find a reason to do so. I wont bore you with mine.

It's always nice to see good advice.  As it happened, I did decide, as you suggested, to do formatting, caps specifically, within Dictation, rather than the new element.  It might be argued though, depending on the element, that there could be a case for some formatting there.  But the advantage, if it's possible, of handling caps in dictation, is that it not only works in the element, but anywhere, for any dictated words.

> PS: You state a difference in behavior between actual use (human

speaking) and "simulation". How do you do such simulation?

I think I posted some code along that line before, but an even simpler version appears below.

Jason

 

# create the element

r=Repetition(sa, min=1, max=7, name="test")

# decode  ("one" "two" are dummy rule names, and get_engine is required at least to handle dictation properly)

# assumed here that decoding finishes on first decode attempt with only single next() call

s = state_.State([  ("a",1000000),("b",1000000)] , ["one" "two"], get_engine())  

s.initialize_decoding()

r.decode(s).next() 

[Charlie Tango]

I like your simulation strategy. If it were possible to add a mock
engine object you could do testing without any speech rec active at
all...