mirror of
https://github.com/facebook/duckling.git
synced 2024-10-26 21:59:44 +03:00
Move Candidate to Ranking/Types.hs
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
This commit is contained in:
parent
69d951220e
commit
81ab073acf
@ -18,12 +18,20 @@ module Duckling.Ranking.Types
|
||||
, Classifier(..)
|
||||
, Classifiers
|
||||
, ClassData(..)
|
||||
, Candidate(..)
|
||||
|
||||
, infinity
|
||||
) where
|
||||
import Data.HashMap.Strict (HashMap)
|
||||
import Data.Text (Text)
|
||||
import Prelude
|
||||
import Duckling.Types
|
||||
( Node(..)
|
||||
, Range(..)
|
||||
, ResolvedToken(..)
|
||||
, Token(..)
|
||||
, isDimension
|
||||
)
|
||||
|
||||
-- -----------------------------------------------------------------
|
||||
-- Aliases
|
||||
@ -55,3 +63,43 @@ data ClassData = ClassData
|
||||
|
||||
infinity :: Double
|
||||
infinity = 1 / 0
|
||||
|
||||
-- -----------------------------------------------------------------
|
||||
-- Candidate
|
||||
|
||||
-- |A Candidate represents a potential match going into the ranker
|
||||
data Candidate = Candidate
|
||||
ResolvedToken -- ^ The actual resolved token we are considering
|
||||
Double -- ^ naive Bayes log-likelihood - sum of LL of all rules used
|
||||
Bool -- ^ Does the ResolvedToken's dimension match the caller's request?
|
||||
deriving (Eq, Show)
|
||||
|
||||
instance Ord Candidate where
|
||||
compare (Candidate Resolved{range = Range s1 e1, node = Node{token = Token d1 _}} score1 t1)
|
||||
(Candidate Resolved{range = Range s2 e2, node = Node{token = tok2}} score2 t2)
|
||||
| isDimension d1 tok2 = case starts of
|
||||
EQ -> case ends of
|
||||
EQ -> compare score1 score2
|
||||
z -> z
|
||||
LT -> case ends of
|
||||
LT -> EQ
|
||||
_ -> GT
|
||||
GT -> case ends of
|
||||
GT -> EQ
|
||||
_ -> LT
|
||||
| t1 == t2 = compRange
|
||||
| t1 && compRange == GT = GT
|
||||
| t2 && compRange == LT = LT
|
||||
| otherwise = EQ
|
||||
where
|
||||
starts = compare s1 s2
|
||||
ends = compare e1 e2
|
||||
-- a > b if a recovers b
|
||||
compRange = case starts of
|
||||
EQ -> ends
|
||||
LT -> case ends of
|
||||
LT -> EQ
|
||||
_ -> GT
|
||||
GT -> case ends of
|
||||
GT -> EQ
|
||||
_ -> LT
|
||||
|
@ -253,43 +253,6 @@ instance Ord ResolvedToken where
|
||||
z -> z
|
||||
|
||||
|
||||
-- |A Candidate represents a potential match going into the ranker
|
||||
data Candidate = Candidate
|
||||
ResolvedToken -- ^ The actual resolved token we are considering
|
||||
Double -- ^ naive Bayes log-likelihood - sum of LL of all rules used
|
||||
Bool -- ^ Does the ResolvedToken's dimension match the caller's request?
|
||||
deriving (Eq, Show)
|
||||
|
||||
instance Ord Candidate where
|
||||
compare (Candidate Resolved{range = Range s1 e1, node = Node{token = Token d1 _}} score1 t1)
|
||||
(Candidate Resolved{range = Range s2 e2, node = Node{token = tok2}} score2 t2)
|
||||
| isDimension d1 tok2 = case starts of
|
||||
EQ -> case ends of
|
||||
EQ -> compare score1 score2
|
||||
z -> z
|
||||
LT -> case ends of
|
||||
LT -> EQ
|
||||
_ -> GT
|
||||
GT -> case ends of
|
||||
GT -> EQ
|
||||
_ -> LT
|
||||
| t1 == t2 = compRange
|
||||
| t1 && compRange == GT = GT
|
||||
| t2 && compRange == LT = LT
|
||||
| otherwise = EQ
|
||||
where
|
||||
starts = compare s1 s2
|
||||
ends = compare e1 e2
|
||||
-- a > b if a recovers b
|
||||
compRange = case starts of
|
||||
EQ -> ends
|
||||
LT -> case ends of
|
||||
LT -> EQ
|
||||
_ -> GT
|
||||
GT -> case ends of
|
||||
GT -> EQ
|
||||
_ -> LT
|
||||
|
||||
data Range = Range Int Int
|
||||
deriving (Eq, Ord, Generic, Hashable, Show, NFData)
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user