Problem with Rule-O-Rama not creating .DMP file

[Paul Cantrell]

I’m trying the demo application with a dictionary based grammar. It was too slow, so I decided to give RuleORama a try. Using the grammar as suggested in the tutorial, I run the generateFastGrammarFromDictionary method and it appears to work, but when I look in the Caches directory (this is on iOS) I just see the .dic file but not the DMP file. Then when I try to start listening, it complains because the .DMP file isn’t there. At first I thought I had broken the code, so I re-downloaded it and tried again and got exactly the same results.

Is it me, or is there a problem with the RuleORama sample?

Here’s the log output:

2014-08-06 16:08:40.227 OpenEarsSampleApp[41364:60b] Dynamic language generator completed successfully, you can find your new files ShareableFirstGrammer.DMP
and
ShareableFirstGrammer.dic
at the paths
/Users/paul/Library/Application Support/iPhone Simulator/7.1/Applications/D9428AA2-036F-4E61-A784-73B51546BF36/Library/Caches/ShareableFirstGrammer.DMP
and
/Users/paul/Library/Application Support/iPhone Simulator/7.1/Applications/D9428AA2-036F-4E61-A784-73B51546BF36/Library/Caches/ShareableFirstGrammer.dic

[Halle Winkler]

Welcome,

Providing a DMP in caches has never been a feature of the demos, but the grammar should work fine when you pass the path to the engine despite the reported error in logging.

[Paul Cantrell]

Halle,

Thank you for the quick reply. I’m seeing weird stuff trying to use the fast grammar… I suspect there are some rules as to what combinations of rules are allowed that I’m not understanding.

I have a grammar which works great if I use generateGrammarFromDictionary but dies if I use generateFastGrammarFromDictionary. I get a few different failures depending on which keywords I use (Can/Will).

This one hangs on startup (but works fine when not “Fast”):
NSDictionary *grammar = @{
OneOfTheseCanBeSaidOnce :
@[
@{ ThisWillBeSaidOnce : @[ @{ThisWillBeSaidOnce : @[@”A S A”] }, @{OneOfTheseCanBeSaidOnce : @[@”1″, @”2″, @”3″, @”4″, @”E”]}]},
@{ ThisWillBeSaidOnce : @[@”PATIENT EDUCATION PROVIDED”]},
@{ ThisWillBeSaidOnce : @[ @{ThisWillBeSaidOnce : @[@”HEART”] }, @{OneOfTheseCanBeSaidOnce : @[@”R R R”, @”OTHER”]}]},
@{ ThisWillBeSaidOnce : @[ @{ThisWillBeSaidOnce : @[@”LUNGS”] }, @{OneOfTheseCanBeSaidOnce : @[@”C T A”, @”OTHER”]}]},
]
};
This one crashes with an Index 1 beyond bounds [0 .. 0]:

NSDictionary *grammar = @{
OneOfTheseWillBeSaidOnce :
@[
@{ ThisCanBeSaidOnce : @[ @{ThisWillBeSaidOnce : @[@”A S A”] }, @{OneOfTheseCanBeSaidOnce : @[@”1″, @”2″, @”3″, @”4″, @”E”]}]},
@{ ThisCanBeSaidOnce : @[@”PATIENT EDUCATION PROVIDED”]},
@{ ThisCanBeSaidOnce : @[ @{ThisWillBeSaidOnce : @[@”HEART”] }, @{OneOfTheseCanBeSaidOnce : @[@”R R R”, @”OTHER”]}]},
@{ ThisCanBeSaidOnce : @[ @{ThisWillBeSaidOnce : @[@”LUNGS”] }, @{OneOfTheseCanBeSaidOnce : @[@”C T A”, @”OTHER”]}]},
]
};
2014-08-06 18:30:05.203 OpenEarsSampleApp[43771:60b] *** Terminating app due to uncaught exception ‘NSRangeException’, reason: ‘*** -[__NSArrayI objectAtIndex:]: index 1 beyond bounds [0 .. 0]’
*** First throw call stack:
(
0 CoreFoundation 0x025571e4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x022d68e5 objc_exception_throw + 44
2 CoreFoundation 0x0250b8b2 -[__NSArrayI objectAtIndex:] + 210
3 OpenEarsSampleApp 0x0011eccb OpenEarsSampleApp + 1170635
4 OpenEarsSampleApp 0x00121743 OpenEarsSampleApp + 1181507
5 OpenEarsSampleApp 0x00121bf0 OpenEarsSampleApp + 1182704
6 OpenEarsSampleApp 0x00121e2d OpenEarsSampleApp + 1183277
7 OpenEarsSampleApp 0x00004595 OpenEarsSampleApp + 13717

I feel like I must be missing a basic concept of how the rules are supposed to work… I’ve read the RuleORama Manual, but it just gives the same example as in the tutorial. Is there some other documentation I should be reading?

Thanks again for any help you can give me…

[Halle Winkler]

Hi Paul,

This sounds a bit like an edge case bug due to RuleORama being quite new, and I may need to add some grammar examples to my testbed. I will check out your example and get back to you.

[Paul Cantrell]

Thanks Halle,

I have a fairly quick deadline to get something working so that the team can decide whether to go with OpenEars or some other recognition system. I’m trying to construct a grammar that will allow accurate filling in of a medical form. The two problems I’m having is getting a grammar fast enough to work (base OpenEars is too slow by the time I have a dozen rules) and how to input numbers (It’s working okay in base OpenEars but I’m using the optional repetitions to allow entry of numbers (so, 231 would be “200 30 1” which I can recognize as a single number and combine. Not sure what to do about that with Rule-O-Rama not allowing optional repetitions. How do people acquire numbers typically? But of course, until I can get a grammar to load without crashing, those issues are moot. Thanks for any help you can give me… We think OpenEars would be great for our project if we can figure out a few of these issues.

[Halle Winkler]

Hi Paul,

Of course I’d like for you to choose OpenEars, but I understand if this bug is a decision factor for you right now since it can only be investigated and fixed in the time available.

Number acquisition with a complex grammar is a somewhat difficult question across all speech solutions (you might see this when Googling it here and at Stack Overflow). But based on your description, it might not be the ideal case for a grammar if the ability to repeat is central to the vocabulary’s utility. Have you tried it as a language model instead of a grammar?

[Paul Cantrell]

Halle,

Thanks for the reply. Of course, the frustrating part is that I had it all working using the base OpenEars grammar, but as I added rules it got slower geometrically. (with 3 or 4 rules it was recognizing in 1-2 seconds, by 12-15 rules it was taking 2 minutes or more).

The ability to repeat is only important as a way to gather numbers, I don’t use it elsewhere in the grammar. For instance, if the user says “Weight 152 pounds” I just encoded all the numbers, (1-10, 10,20,..100, 100,200,300) with an optional repeat and then post processed the “100 50 2” as 152. Pretty ugly, I know, but worked fairly well.

I’ll do some research into language model vs grammar, are you suggesting that I might want to plug in my own language model into Open Ears, or were you speaking more generically? Maybe you could suggest a google search or a seminal web site where I could look that up?

Right now my fallback strategy is to keep the number of rules small enough that base OpenEars would have the required speed, but that’s probably not a good long term strategy (4 or so rules at a time is pretty limiting). Or else maybe you will find the bug in Rule-O-Rama and I can make that work (but I don’t know how I’ll handle numbers in that case).

Sorry to take so much of your time…

Paul

[Halle Winkler]

Hi Paul,

The geometric slowdown is going to be largely due to the optional repetitions – it’s the reason they had to be cut from RuleORama. They create a really big search space. JSGF grammars without optional repetitions are also a lot slower than language models, and RuleORama can help with that kind of grammar, but there is little to be done about unbounded repetitions causing slowdowns in a grammar.

OpenEars also has an easy system for creating probabilistic language models instead of grammars (it’s even easier to use than the grammar system). Just check out the sample app or tutorial’s example of creating a language model, or the docs about LanguageModelGenerator’s method:

- (NSError *) generateLanguageModelFromArray:(NSArray *)languageModelArray withFilesNamed:(NSString *)fileName forAcousticModelAtPath:(NSString *)acousticModelPath;

[Halle Winkler]

OK, so the crasher is due to an actual logical contradiction in the ruleset (although it is a bug that this results in a crash rather than a helpful message or a helpful best-effort attempt to fulfill the request).

The contradiction is that you have a rule “OneOfTheseWillBeSaidOnce” (so far so good) but all of the top-level rules contained in that are “ThisCanBeSaidOnce”, meaning that there is also a state in which none of the statements will be uttered and that is valid. That means that a nonexistent statement is one of the things in the set of utterances that will be said, and that makes RuleORama sad. It runs if I change one of the “CanBeSaid” rules to a “WillBeSaid” (I presume it will also run if I change them to expected strings rather than more rules).

Stock OpenEars deals with this gracefully but it is still possible that it is leading to undesired results that are less obvious. To troubleshoot the one that hangs, just turn on all the logging (OpenEarsLogging and verbosePocketsphinx) and it will probably give an actual error or warning about the cause of the hang.

[Author]

Posts