Summary:
The commit adds a rule and an underlying parser for German numeral expressions representing (integer) numbers smaller than 1 million. Other than in English, those numbers are represented by single words, e.g. "neunhundertsiebenundachtzigtausendsechshundertvierundfünfzig" (987654). Other rukes are simplified or removed to eliminate redundancies.
Pull Request resolved: https://github.com/facebook/duckling/pull/699
Reviewed By: patapizza
Differential Revision: D37716120
Pulled By: stroxler
fbshipit-source-id: 90b26e253259c5bc1aaa76f3972537c2361f6bb3
Summary: Pull Request resolved: https://github.com/facebook/duckling/pull/682
Test Plan:
CI tests look clean.
As for the German language, I got a friend to double check and the code + test case look good (see Github comment)
Reviewed By: girifb
Differential Revision: D34248572
Pulled By: stroxler
fbshipit-source-id: a031a07808f9aaab142aa365d012035e277676ca
Summary:
* as title
* refactored `numberBetween` to be a `Predicate`
Reviewed By: nishsinghal20
Differential Revision: D34180649
fbshipit-source-id: 8fbe6db83e8b22181bd0bbde533e2d3390d24c75
Summary:
In theory, years can be negative. In practice, this is rarely seen and when it is, it's usually with the B.C. postfix.
Updating `ruleYearLatent` to not accept negative years for all languages.
Reviewed By: codyohl
Differential Revision: D33895871
fbshipit-source-id: 818000104da825aab91be7fa2a72704aa350a91a
Summary:
Some changes were originally suggested by me during the review of
https://github.com/facebook/duckling/pull/474.
Others are new.
1. "Day after tomorrow/before yesterday"
2. Ordinals in the form of number+suffix like "8th of March"
3. Tuesdays require a special preposition.
4. Support "Yo" (U+0451) in "fourth" and "during daylight".
5. Support special perposition for "next week".
6. Support "one before last" adjective for time grains.
7. Proper suffixes for "quarter" grain.
8. Support "at midnight".
9. Support alternative flag for "afternoon".
Changes in Ordinal and TimeGrain are all driven by the new examples in the
corpus for Time.
There are also a couple of bugfixes:
1. A hidden latin "e" was present in an otherwise Cyrillic regex.
2. Wrong order of options in a regex separated with "|" prevented some matches.
Reviewed By: haoxuany
Differential Revision: D32311714
fbshipit-source-id: 084f6c3893eb5bfd767c267f558b910c6854eb59
Summary:
Add the most common rules for Japanese time dimension.
Pull Request resolved: https://github.com/facebook/duckling/pull/646
Reviewed By: stroxler
Differential Revision: D30675005
Pulled By: chessai
fbshipit-source-id: 917aa98b5cfe0c73d207b1f51b80d8e17a1c7e6a
Summary: An interval regex was overzealous and matching too much, so `hh:mm:ss` was getting parsed as an interval instead of a time.
Reviewed By: patapizza
Differential Revision: D30608223
fbshipit-source-id: b24c18146070f15ada80b9401e67f0c0aefef7d8
Summary:
Some time recognition improvements for Catalan:
- morning should be a time range recognised until noon
- "dema" can also be used for tomorrow (besides "demà")
- "se" alone should not be understood as September
Pull Request resolved: https://github.com/facebook/duckling/pull/639
Reviewed By: stroxler
Differential Revision: D30312076
Pulled By: chessai
fbshipit-source-id: 1a42bbd7eecc4f5690145ee9cadb8eccae8edd08
Summary:
I'm using Duckling in my project but I noticed that quantities in kg weren't being detected correctly, though other entities such as numeral/volume were all working as expected. Investigating more I noticed that this was just because in Portuguese the Quantity entity was only configured to detect cups and pounds, never grams. And even for cups/pounds, products weren't being detected correctly.
So I've just adapted the rules from English Quantity to work in Portuguese as well, while keeping the cups/pounds too. It's all working as expected now and it's backwards compatible.
Pull Request resolved: https://github.com/facebook/duckling/pull/631
Reviewed By: stroxler
Differential Revision: D29701339
Pulled By: chessai
fbshipit-source-id: fca08a14c50844d418f101b885ca54554d993f58
Summary:
add ruleLeadingDotNumeral which parses "punto 2" and "coma 2" as 0.2, and allow "coma" in ruleNumeralDotNumeral.
Also extend ruleNumeralsPrefixWithNegativeOrMinus to include 'negativo' prefixes
Reviewed By: stroxler
Differential Revision: D29405886
fbshipit-source-id: eb43f6f72374430af414e0d29009b98df2115a31
Summary: Initialise Time for CA (Catalan) language
Reviewed By: stroxler
Differential Revision: D28455273
Pulled By: chessai
fbshipit-source-id: be9a4d61692ba4fb32986e161e9fdd6d25a357dc
Summary:
I don't think abbreviating pattern to ptn is a win, the abbreviation
isn't good enough to be unambiguous (I found this because I was
trying to figure out what "ptn" meant), and `pattern` isn't that
long a name.
Reviewed By: chessai
Differential Revision: D28462776
fbshipit-source-id: bd685720b198fed791d84c00732eb1873b37528b
Summary:
Solutions were:
- use targeted and qualified imports to avoid pulling in the universe of Duckling.Types
- use long-form descriptive names in a few places
- shuffle a let clause to just define an output instead of a local func
Also got rid of another lint error suggesting to use a section instead of flip;
the module is now lint-warning free.
Reviewed By: chessai
Differential Revision: D28462775
fbshipit-source-id: 1e2855756b22cb62db0d94334a7e063aa728b7bf
Summary:
Using rules of thumb:
- use unabbreviated names for aguments to top-level functions where there's
a clash (e.g. lots of t -> time transformations)
- use abbreviated names for nested local functions (so e.g. t, d to avoid
a clash with the `day` top-level function)
Reviewed By: chessai
Differential Revision: D28462777
fbshipit-source-id: 8795d038b2c3a65b60f0d2d9091b7c56cc8a5ff7
Summary:
In my opinion putting `Candidate` into the core `Types.hs`
is a mistake - it's used exclusively in the ranking stage, so cluttering
the core tokenizing and recursive parsing / value resolution logic in
`Duckling.Types` with this irrelevant datatype makes things less clear
than if we keep it in the `Ranking` modules.
Reviewed By: chessai
Differential Revision: D28462902
fbshipit-source-id: cd4bb88c4a16945265e8f21c8808b06ae3383559
Summary: There are different implementations of isRangeValid that work well for different languages, thus it makes sense to facilitate having different implementations based on the language.
Reviewed By: patapizza
Differential Revision: D28362777
fbshipit-source-id: 5f2991d54af3095c8e95cf534e2dd3b4a34dee3a
Summary:
In ES (Spanish), decimals can be expressed by `<number> con <number>`, where the whole part is to the left and the decimal part is to the right.
Resolves#615
Reviewed By: stroxler
Differential Revision: D28449722
fbshipit-source-id: caa0fb52f72f94c4a4cc456a46c25fa5f3b9b625
Summary:
Make the code reflect the call graph, which looks roughly like this:
```
parseAndResolve
runDuckling
resolveNode
parseString
saturateParseString
parseString1
matchFirst
... low level stuff
matchFirstAnywhere
... low level stuff
```
I found the existing order pretty hard to untangle when I was writing some architecture notes on this module, I think the new ordering will help
Reviewed By: chessai
Differential Revision: D28441933
fbshipit-source-id: 07c722aa6d4038baa7f14fec84660ecc2736ed2e
Summary: Some classifiers were a bit out of date. They needed regenerating.
Reviewed By: girifb
Differential Revision: D28399234
fbshipit-source-id: 2780dbe5478a5386a2b6062dec8696736b3ce723
Summary:
I spent a surprising amount of time trying to figure out what
this comment was referring to because it wasn't at all clear to me
that it meant a comment in another file. Making it more specific
Reviewed By: chessai
Differential Revision: D28411103
fbshipit-source-id: 26cd29b47367a7e0d865f616f289fef570544c39
Summary:
When documenting `Types.hs` last week I got confused about what the Bool
represented here, following up on a suggestion to add a doc comment
Reviewed By: chessai
Differential Revision: D28412103
fbshipit-source-id: 01af1f0831fc3e49d4b7f5bb9a4e89c5897b3d25
Summary: Just replace `.` with `$`, also tweaked the spacing a bit for skimmability
Reviewed By: chessai
Differential Revision: D28411898
fbshipit-source-id: d18b9ef5db99b82d150231080c89f812f709f409
Summary: Use targeted imports to avoid clash on `node` variable name
Reviewed By: chessai
Differential Revision: D28411902
fbshipit-source-id: 4a81e35a6aa601015685ccab3f571e919e9025c8
Summary: Initialise Temperature for CA (Catalan) language
Reviewed By: stroxler
Differential Revision: D28298423
Pulled By: chessai
fbshipit-source-id: 73b87d002196b6b707388e9f83f42591510f40eb
Summary: Currently, Duckling will accept "The first christmas of next month" in this rule, which is nonsensical. This reduces the scope of the times the rule recognises, thereby limiting us to a set of more sensible resolutions.
Reviewed By: stroxler
Differential Revision: D27861417
fbshipit-source-id: 3f19700af7298a6238c59f5de0598168d4b4a3c4
Summary:
Support numerals like "forty-five (45)". Commonly seen in legal documents.
There are no classifiers to regenerate.
Resolves#216
Reviewed By: stroxler
Differential Revision: D28305725
fbshipit-source-id: b9b4e160f630ce3cf462fcf9f2e575738463c313
Summary:
I think they all fell into one of two categories:
- names colliding with field names, but where there was already an existing
pattern (e.g. d for dimension, v for value) and we just had to be consistent
- cases that were best fixed by turning NamedFieldPuns on, which I did
Reviewed By: chessai
Differential Revision: D28213245
fbshipit-source-id: 18fbd61771e12da11ce03b98b74af51d1e837787