Below are a variety of topics covered in greater depth or of more specialized interest than found in the Quick Tour. Reading the Quick Tour first is recommended.

## Arc Iterators

An arc iterator %DOX{fst::ArcIterator[]}% is used to access the transitions leaving an FST state. It has the form:

```template <class F>
class ArcIterator {
typedef typename F::Arc Arc;
typedef typename Arc::StateId StateId;

public:
ArcIterator(const &F fst, StateId s);
// End of iterator?
bool Done() const;
// Current arc (when !Done)
const Arc& Value() const;
// Advances to next arc (when !Done)
void Next();
// Returns current position
size_t Position();
// Returns to initial position
void Reset();
// Arc access by position
void Seek(size_t pos);
// Returns arc flags
uint32 Flags() const;
// Sets arc flags
};
```

It is templated on the Fst class `F` to allow efficient specializations but defaults to a generic version on the abstract base Fst class.

See here for conventions that arc iterator use must respect.

All current OpenFst library `Seek()` methods are constant time.

An example use of an arc iterator is shown here.

A `MutableArcIterator` %DOX{fst::MutableArcIterator[]}% is similar to an `ArcIterator` except its constructor takes a pointer to a `MutableFst` and it additionally has a `SetValue()` method.

## Arc Filters

Arc filters are accepted by various operations to control which arcs are transitioned. An arc filter has the form:

```template <class Arc>
class SomeArcFilter {
public:
// Return true iff arc is to be transitioned.
bool operator()(const Arc &arc) const;
};
```

Pre-defined arc filters include:

Name Description
`AnyArcFilter` Accept all arcs %DOX{fst::AnyArcFilter[]}%
`EpsilonArcFilter` Accept only arcs with input and output epsilons %DOX{fst::AnyArcFilter[]}%
`InputEpsilonArcFilter` Accept only arcs with input epsilons %DOX{fst::InputEpsilonArcFilter[]}%
`OutputEpsilonArcFilter` Accept only arcs with output epsilons %DOX{fst::InputEpsilonArcFilter[]}%

## Arc Mappers

Arc mappers are function objects used by the ArcMap operation to transform arcs and/or final states. An arc mapper has the form:

```// This determines how final weights are mapped.
enum MapFinalAction {
// A final weight is mapped into a final weight. An error
// is raised if this is not possible.
MAP_NO_SUPERFINAL,

// A final weight is mapped to an arc to the superfinal state
// when the result cannot be represented as a final weight.
// The superfinal state will be added only if it is needed.
MAP_ALLOW_SUPERFINAL,

// A final weight is mapped to an arc to the superfinal state
// unless the result can be represented as a final weight of weight
// Zero(). The superfinal state is always added (if the input is
// not the empty Fst).
MAP_REQUIRE_SUPERFINAL
};

// This determines how symbol tables are mapped.
enum MapSymbolsAction {
// Symbols should be cleared in the result by the map.
MAP_CLEAR_SYMBOLS,

// Symbols should be copied from the input FST by the map.
MAP_COPY_SYMBOLS,

// Symbols should not be modified in the result by the map itself.
// (They may set by the mapper).
MAP_NOOP_SYMBOLS
};

class SomeArcMapper {
public:
// Assumes input arc type is A and result arc type is B
typedef A FromArc;
typedef B ToArc;

// Maps an arc type A to arc type B.
B operator()(const A &arc);
// Specifies final action the mapper requires (see above).
// The mapper will be passed final weights as arcs of the
// form A(0, 0, weight, kNoStateId).
MapFinalAction FinalAction() const;
// Specifies input symbol table action the mapper requires (see above).
MapSymbolsAction InputSymbolsAction() const;
// Specifies output symbol table action the mapper requires (see above).
MapSymbolsAction OutputSymbolsAction() const;
// This specifies the known properties of an Fst mapped by this
// mapper. It takes as argument the input Fst's known properties
uint64 Properties(uint64 props) const;
};```

The following arc mappers are defined in the OpenFst library:

Name Description
`FromGallicMapper` Extracts output label from gallic weight %DOX{fst::FromGallicMapper[]}%
`IdentityArcMapper` Maps to self %DOX{fst::IdentityArcMapper[]}%
`InvertWeightMapper` Reciprocate all non-0 weights %DOX{fst::InvertWeightMapper[]}%
`PlusMapper` Adds (⊕) a constant to all weights %DOX{fst::PlusMapper[]}%
`QuantizeMapper` Quantize all weights %DOX{fst::QuantizeMapper[]}%
`ReverseWeightMapper` Reverse all weights %DOX{fst::ReverseWeightMapper[]}%
`RmWeightMapper` Map all non-0 weights to 1 %DOX{fst::RmWeightMapper[]}%
`SuperFinalMapper` Redirects final states to new superfinal state %DOX{fst::SuperFinalMapper[]}%
`TimesMapper` (Right) multiplies (⊗) a constant to all weights %DOX{fst::TimesMapper[]}%
`ToGallicMapper` Combines output label and weight into gallic weight %DOX{fst::ToGallicMapper[]}%
`WeightConvertMapper` Converts arc weight types (assuming appropriate `WeightConvert` class specialization), leaving labels and nextstates the same. %DOX{fst::WeightConvertMapper[]}%

`ToGallicMapper` and `FromGallicMapper` are used, for example, to implement transducer determinization and minimization using weighted acceptor versions of these algorithms. Other specialized arc mappers are used to implement Decode, Encode, Invert, and Project.

## Arcs

An `Arc` is a type that represents an FST transition from a given source state. It specifies an input label, an output label, a weight, and a destination state ID and it has a type name. In particular, it has the following form:

```struct SomeArc {
typedef W Weight;
typedef L Label;
typedef S StateId;

static const string &Type();

Label ilabel;
Label olabel;
Weight weight;
StateId nextstate;
};
```

where `W` is a valid weight type, and `L` and `S` are signed integral types.

The following arc types are defined in the OpenFst library:

Name Label Type State ID Type Weight Type Registered
`ExpectationArc<A, W>` `int` `int` `ExpectationWeight<A::Weight, W>`
`GallicArc<A, S>` `A::Label` `A::StateId` `GallicWeight<A::Label, A::Weight, S>`
`LexicographicArc<W1, W2>` `int` `int` `LexicographicWeight<W1, W2>`
`LogArc` `int` `int` `LogWeight`
`Log64Arc` `int` `int` `Log64Weight`
`MinMaxArc` `int` `int` `MinMaxWeight`
`PowerArc<A, n>` `int` `int` `PowerWeight<A::Weight, n>`
`ProductArc<W1, W2>` `int` `int` `ProductWeight<W1, W2>`
`SignedLogArc` `int` `int` `SignedLogWeight`
`SignedLog64Arc` `int` `int` `SignedLog64Weight`
`SparsePowerArc<A>` `int` `int` `SparsePowerWeight<A::Weight>`
`StdArc` `int` `int` `TropicalWeight`
`StringArc<S>` `int` `int` `StringWeight<int, S>`

## Base Fsts

Every `Fst` %DOX{fst::Fst[]}% must specify an initial state, the final weights, arc and epsilon counts per states, an Fst type name, the Fst's properties, how to copy, read and write the Fst, and the input and output symbol tables (if any). In particular, the base `Fst` class has the interface:

```template <class A>
class Fst {
public:
typedef A Arc;
typedef typename A::Weight Weight;
typedef typename A::StateId StateId;

// Initial state
virtual StateId Start() const = 0;
// States's final weight
virtual Final(StateId) const = 0:
// State's arc count
virtual NumArcs(StateId) const = 0;
// States's input epsilon count
virtual NumInputEpsilons(StateId) const = 0;
// State's output epsilon count
virtual NumOutputEpsilons(StateId) const = 0;
// If test=false, return stored properties bits for mask (some poss. unknown)
// If test=true, return property bits for mask (computing o.w. unknown)
virtual Properties(uint64 mask, bool test) const = 0;
// Fst type name
virtual const string& Type() const = 0;
// Get a copy of this Fst
virtual Fst<A> *Copy() const = 0;
// Read an Fst from an input stream; returns NULL on error
// Read an Fst from a file; return NULL on error
// Empty filename reads from standard input
// Write an Fst to an output stream; return false on error
virtual bool Write(ostream &strm, const FstWriteOptions &opts);
// Write an Fst to a file; return false on error
// Empty filename writes to standard output
virtual bool Write(const string &filename);
// Return input label symbol table; return NULL if not specified
virtual const SymbolTable* InputSymbols() const = 0;
// Return output label symbol table; return NULL if not specified
virtual const SymbolTable* OutputSymbols() const = 0;
};
```

`Fst` is an abstract class (note the pure virtual methods). All OpenFst FSTs must meet this interface.

The companion state iterator and arc iterator classes provide access to the states and transitions of the FST.

## Caching

Most of the delayed Fst classes use internal caching to save expanded states and arcs. This caching is controlled by this struct:

```struct CacheOptions {
// enable GC
bool gc;
// # of bytes allowed before GC
size_t gc_limit;

CacheOptions(bool g, size_t l) : gc(g), gc_limit(l) {}
CacheOptions()
: gc(FLAGS_fst_default_cache_gc),
gc_limit(FLAGS_fst_default_cache_gc_limit) {}
};```

All OpenFst cached Fsts have constructors that accept this (or a class derived from it) as an argument. The member defaults are controlled by global flags. These options can be used for:

• Maximal caching: If `gc` is `false`, then any expanded state will be cached for the extent of the FST. This case is useful when states are revisited and memory is not a concern.

• Bounded caching: If `gc` is `true`, then the cache will be garbage-collected when it grows past `gc_limit`. This case is useful when states are revisited and memory is a concern. This is the default case (based on the global flags).

• Minimal caching: It is generally not possible to avoid all caching in such an FST since the cache is used to implement the arc iterators efficiently (creating an iterator computes and writes the state's arcs to the cache, iterating reads from the cache). However, if (1) `gc` is `true`, (2) `gc_limit` is 0, and (3) arcs iterators have been created (and then destroyed) only one state at a time, then only information for that state is cached and this case is especially optimized. This case is useful when states are not revisited (e.g. when a cached FST is simply being copied to a mutable FST).

The default cache storage (VectorCacheStore) maintains a vector of state pointers; the pointed to objects are GCed but the vector is never shrunk (see cache.h for other cache stores). Also delayed operations typically maintain an internal state table between the output state and the essential computation state (such as the corresponding state pair in composition) that is not GCed (since the consumer may come back to that state). As such, delayed operations that continue to grow in states will continue to consume memory. Some key operations, like ComposeFst, let you change the cache store and the state table to allow customization such as described here.

## Command Line Flags

OpenFst has several global options in the library proper that most users can ignore, leaving them with their default values:

Option Type Default Description
`FLAGS_fst_compat_symbols` bool true Require symbol tables to match when appropriate
`FLAGS_fst_default_cache_gc` bool true Enable garbage collection of cached Fsts
`FLAGS_fst_default_cache_gc_limit` int64 1048576 Byte size that triggers garbage collection of cached Fsts
`FLAGS_fst_error_fatal` bool true FST errors are fatal; o.w. return objects flagged as bad: e.g., FSTs - `kError` prop. true, FST weights - not a `Member()`
`FLAGS_fst_field_separator` string " \t" Set of characters used as a separator between printed fields
`FLAGS_fst_weight_parentheses` string "" Characters enclosing the first weight of a printed composite weight (and derived classes) to ensure proper I/O of nested composite weights; must have size 0 (none) or 2 (open and close parenthesis)
`FLAGS_fst_weight_separator` string "," Character separator between printed composite weights; must be a single character
`FLAGS_fst_verify_properties` bool false Verify Fst properties are correctly set when queried

The first ensures the arguments of binary FST operations (e.g. composition) have compatible symbol tables (e..g output symbol table matches input symbol table for composition). The second two are used to control the caching of expanded state and arc information found in most delayed Fst classes; the default values should normally be satisfactory. The next determines how errors are handled. The next is used in the textual representation of FSTs and symbol tables. The next two are used to control the text formating of ProductWeight and other weight tuples. The last is used to ensure that the properties of an FST have been correctly set; it is used for debugging only since it incurs considerable computational cost.

In each of the Fst distribution installed binaries, the above options, as well as any of those defined specific to the binary, can be set from the command line using e.g. `--fst_default_cache_gc=false` or `--fst_weight_parenthesis="("` . Additionally, the option `--help` and `--v=N` (where N = 0,1,2,..) will print out usage information and set the verbosity level of logging, respectively. The flag processing is modeled after the Google gflags package.

In a user-defined binary, the command line options processing will all also work if the user calls:

```SetFlags(usage, &argc, &argv, true);
```

In that case, the user can set his own flags as well, following the conventions in <fst/flags.h>.

Alternatively, the user can process options in his own way and directly assign to any of the above global options if he wishes to modify their defaults.

## Composition Filters

A composition filter determines which matches are allowed to proceed in composition. The basic filters handle correct epsilon matching. In particular, they ensure that redundant epsilon paths, which would be incorrect with non-idempotent weights, are not created. More generally, composition filters can be used to block or modify composition paths for efficiency or other purposes usually working in tandem with specialized matchers. Their interface is:

```template <class M1, M2>
class SomeComposeFilter {
public:
typedef typename M1::FST1 FST1;
typedef typename M1::FST2 FST2;
typedef typename FST1::Arc Arc;
typedef ... FilterState;
typedef ... Matcher1;
typedef ... Matcher2;
typedef ... FilterState;

typedef typename Arc::StateId StateId;
typedef typename Arc::Weight Weight;

// Required constructor. The filter is either passed composition matchers or constructs
// them internally. This is done so the filter can possibly modify the result (useful e.g. with lookahead).
SomeComposeFilter(const FST1 &fst1, const FST2 &fst2, M1 *matcher1 = 0, M2 *matcher2);
// Return start state of filter.
FilterState Start() const;
// Specifies current composition state.
void SetState(StateId s1, StateId s2, const FilterState &f);
Matcher2 *GetMatcher2();

// Apply filter at current composition state to these transitions.
// If an arc label to be matched is kNolabel, then that side does not consume a symbol.
// Returns the new filter state or, if disallowed, FilterState::NoState().
// The filter is permitted to modify its inputs, e.g. for optimizations.
FilterState FilterArc(A *arc1, A *arc2) const;

// Apply filter at current composition state to these final weights
// (cf. superfinal transitions). The filter may modify its inputs,
// e.g. for optimizations.
void FilterFinal(Weight *final1, Weight *final2) const;

// Return resp matchers. Ownership stays with the filter. These
// methods allow the filter to access and possibly modify
// the composition matchers (useful e.g. with lookahead).
Matcher1 *GetMatcher1();
};
```
The filter's state is represented by the type `SomeComposeFilter::FilterState` and is stored in the composition state table tuple. It has the form:

```class SomeFilterState {
public:
// Required constructors
SomeFilterState();
SomeFilterState(const SomeFilterState &f);
// An invalid filter state.
static const SomeFilterState NoState();
// Maps state to integer for hashing.
size_t Hash() const;
// Equality of filter states.
bool operator==(const SomeFilterState &f) const;
// Inequality of filter states.
bool operator!=(const SomeFilterState &f) const;
// Assignment to filter states.
SomeFilterState& operator=(const SomeFilterState& f);
};
```

The following composition filters are defined in the OpenFst library:

Name Description
`SequenceComposeFilter` Requires epsilons on FST1 to be read before epsilons on FST2 %DOX{fst::SequenceComposeFilter[]}%
`AltSequenceComposeFilter` Requires epsilons on FST2 to be read before epsilons on FST1 %DOX{fst::AltSequenceComposeFilter[]}%
`MatchComposeFilter` Requires epsilons on FST1 to be matched with epsilons on FST2 whenever possible %DOX{fst::MatchComposeFilter[]}%
`LookAheadComposeFilter` Used with a lookahead matcher to block non-coaccessible paths %DOX{fst::LookAheadComposeFilter[]}%
`PushWeightsComposeFilter` Adds weight-pushing to a lookahead composition filter %DOX{fst::PushWeightsComposeFilter[]}%
`PushLabelsComposeFilter` Adds label-pushing to a lookahead composition filter %DOX{fst::PushLabelsComposeFilter[]}%

`SequenceComposeFilter` is the default composition filter. It can be changed by using the version of `ComposeFst` that accepts `ComposeFstOptions`.

## Error Handling

If `FLAGS_fst_error_fatal` is true (the default), then most serious errors cause program exit. The exception are most functions and methods that return NULL, a boolean, or `NoWeight()` on error - typically I/O and weight operations. If `FLAGS_fst_error_fatal` is false, then no operation is fatal. In that case, operations that return FSTs set the `kError` property bit. Otherwise classes have an Error() method that should be checked and functions return a boolean. It is intended that a sequence of operations preserve the `kError` property bit and the `NoWeight()`, so that it should suffice to check for error at the end of the sequence.

## Expanded Fsts

An `ExpandedFst` %DOX{fst::ExpandedFst[]}% is an Fst that has an additional method that specifies the state count as well as methods to copy and read the expanded FST. In particular, an `ExpandedFst` class has the interface:

```template <class A>
class ExpandedFst : public Fst<class A> {
public:
typedef A Arc;
typedef typename A::StateId StateId;

// State count
StateId NumStates();
// Get a copy of this ExpandedFst
virtual ExpandedFst<A> *Copy() const = 0;
// Read an ExpandedFst from an input stream; returns NULL on error
// Read an ExpandedFst from a file; return NULL on error
// Empty filename reads from standard input
};
```

`ExpandedFst` is an abstract class (note the pure virtual methods). Examples are `VectorFst` %DOX{fst::VectorFst[]}% and `ConstFst` %DOX{fst::ConstFst[]}%

## FST Input/Output

The following describes methods for reading and writing binary file representations of FSTS. Note these binary file representations are machine architecture dependent; use the textual file format cross-platform independence.

The code:

```VectorFst<Arc> ifst;
...
ifst.Write("a.fst");
```

writes and reads a defined Fst type (`VectorFst`) and arc type (`Arc`) to and from a file in a straight-forward way.

### Library Registration

The call:

```Fst<Arc> *fst = Fst<Arc>::Read("a.fst");
```

reads the same `VectorFst` from the file as above, but returns a base `Fst`. This form, useful for code that works generically for different Fst types, can not work unless the Fst and arc type are appropriately registered. Some arc types (see here) are already registered for common Fst types defined in the OpenFst library. Other arc type `Arc` and Fst type `F` pairs can be registered with the following call:

```REGISTER_FST(F, Arc);
```

To avoid code bloat in a given program, registering arc types, in particular, should be used sparingly.

### Script Registration

In the above examples, the user provided the arc type as a template parameter. However, the call:

```\$ fstdeterminize in.fst >out.fst
```

works e.g. for both `StdArc` and `LogArc` arcs. This is accomplished by calling in `main(argc, argv)`:

```namespace script {
VectorFstClass ofst(ifst->ArcType());
Determinize(*ifst, &ofst);
ofst.Write(out_name);
}
```

where:

```class VectorFstClass;
void Determinize(const FstClass &ifst, MutableFstClass *ofst);
```

are a class and function in the fst:script namespace that do not depend on the `Arc` template parameter. These forms, useful for code that works generically for different Arc types, can not work unless the arc type is appropriately registered. Some arc types (see here) are already registered. Other arc types `Arc` can be registered with the following calls:

```REGISTER_FST_CLASS(VectorFstClass, Arc);
REGISTER_FST_OPERATION(Determinize, Arc, DeterminizeArgs);
```

If `Arc` defines a new weight type, it can be registered at the script level (enabling WeightClass support) with the call:

```REGISTER_FST_WEIGHT(Arc::Weight);
```

To avoid code bloat in a given program, registering arc types should be used sparingly.

### FST Dynamic Shared Objects

The examples above show how users can modify programs to be able to read new arc and Fst types. However, it would not be ideal to have to do so for all the distribution binaries or other existing programs. Instead, this can be done more easily with dynamic shared objects (DSOs).

To add a new Fst type, `MyFst` with `MyFst::Type()` = `"my_fst"`, use the code:

```// Register some arc types with this Fst type
REGISTER_FST(MyFst, StdArc);
REGISTER_FST(MyFst, LogArc);
```

compiled into a dynamic shared object `my_fst.so`. If `my_fst.so` can be found in the `LD_LIBRARY_PATH` (or equivalent), you should be able to read the new Fst type with existing programs.

To add a new arc type, `MyArc` with `MyArc::Type()` = `"my_arc"`, use the code:

```
// Register some Fst types with this arc type
REGISTER_FST(VectorFst, MyArc);
REGISTER_FST(ConstFst, MyArc);

// Register the fst::script operations with this arc type
REGISTER_FST_OPERATIONS(MyArc);
// Register some other operation with this arc type
REGISTER_FST_OPERATION(Operations, MyArc, Args);
```

compiled into a dynamic shared object `my_arc.so`. If can be found in `LD_LIBRARY_PATH` (or equivalent), you should be able to read the new arc type with existing programs.

## fst::script

The OpenFst library offers an additional abstraction layer that facilitates scripting with FSTs of different arc types. It allows users to load FSTs and perform various operations on them without specifying the underlying FST arc types. This higher-level layer, found in the `fst::script` namespace, is somewhat less efficient, due to indirection, and in general exposes fewer methods and options. It is used principally to implement the shell-level FST commands and Python bindings. From C++, users are encouraged in most circumstances to use the lower-level templated classes and operations for their efficiency and completeness. However, for simple 'glue' code that will work seamlessly with different arc types (esp. I/O), this higher-level might be appropriate. To use the scripting layer, include `<fst/fstscript.h>` in the installation include directory and link to `libfstscript.{a,so}` in the installation library directory. The extension libraries work similarly; e.g. for the FAR extension, include `<fst/extension/farscript.h>` and link to `lib/libfstfarscript.{a,so}`.

In the following, all classes and methods mentioned are in the namespace fst::script.

### Class Overview

At FST script level, the `Fst<Arc>` class template hierarchy is partially mirrored with a template-free `FstClass` hierarchy. For example, these classes are defined:

#### FstClass

```class FstClass {
public:
// Construct an FstClass from a templated Fst, hiding its arc type.
template<class Arc>
explicit FstClass(const Fst<Arc> &fst);
// Copy constructor
explicit FstClass(const FstClass &other);
// Read an arc-templated Fst from disk, and return as an FstClass
// String representation of the arc type
virtual const string &ArcType() const;
// String representation of the underlying Fst type (e.g. 'vector')
virtual const string &FstType() const;
// String representation of the arc's weight type
virtual const string &WeightType() const;
// A pointer to this Fst's input symbol table
virtual const SymbolTable *InputSymbols() const;
// A pointer to this Fst's output symbol table
virtual const SymbolTable *OutputSymbols() const;
// Write the underlying arc-templated Fst to disk
virtual void Write(const string &fname);
// Return an integer representing all the properties (see Fst::Properties)
virtual uint64 Properties(uint64 mask, bool test) const;
// Call to get the underlying FST, if you know the concrete arc type
// e.g. for an FstClass fc,
// const Fst<StdArc> &f = *(fc.GetFst<StdArc>());
// Returns NULL if the given arc type doesn't match the underlying FST.
template<class Arc>
const Fst<Arc> *GetFst() const;

virtual ~FstClass();
}
```

Unlike its lower-level analogue Fst<Arc>, FstClass is not abstract; it is a container which can be constructed from an arbitrary Fst<Arc>.

#### MutableFstClass

```class MutableFstClass : public FstClass {
public:
// Construct a MutableFstClass from some kind of MutableFst<>
template<class Arc>
explicit MutableFstClass(const MutableFst<Arc> &fst);
// If your code knows the arc type of the underlying MutableFst<>, it
// can use this method to extract a pointer to it. This pointer can be used
// to change the underlying MutableFst<>
template<class Arc>
MutableFst<Arc> *GetMutableFst();
// Set the input symbol table of the underlying MutableFst
virtual void SetInputSymbols(SymbolTable *is);
// Set the output symbol table of the underlying MutableFst
virtual void SetOutputSymbols(SymbolTable *os);
};
```

#### VectorFstClass

```class VectorFstClass : public MutableFstClass {
public:
// Construct a copy of "other" as a VectorFstClass
explicit VectorFstClass(const FstClass &other);
// Construct a blank VectorFstClass with the given arc type
explicit VectorFstClass(const string &arc_type);
// Wrap the given VectorFst<Arc>
template<class Arc>
explicit VectorFstClass(VectorFst<Arc> *fst);
};
```

#### WeightClass

This class hides the weight type similar to how the classes above hide the arc type of an FST. It is useful for weight I/O and for passing weights into the operations that require them.

```class WeightClass {
public:
// Construct a Zero
WeightClass();
// Wrap a weight of the given type
template<class W>
explicit WeightClass(const W &weight);
// Construct a weight given the string representation of its type
// (e.g. "tropical") and a string representation of the weight
// itself.
WeightClass(const string &weight_type, const string &weight_str);
// Copy constructor and assign
WeightClass(const WeightClass &other);
WeightClass &operator = (const WeightClass &other);
// If you know the correct weight type, you can get it with this
method. Will return NULL if an incorrect type is attempted.
template<class W>
W *GetWeight() const;
// Constants representing zero and one in all possible weight types
static const WeightClass &Zero();
static const WeightClass &One();

~WeightClass();
};
```

### Operations

In general, many of the operations that are implemented for the underlying templated FSTs are implemented for instances of FstClass, sometimes with modified option lists. Check `<fst/fstscript.h>`.

### Example

The code in the quick tour could be reimplemented using the fst::script library as follows. This new version will work with FSTs of all arc types, not just StdArc (though the arc types in input.fst and model.fst must match).

```// Reads in an input FST.
// Reads in the transduction model.

// The FSTs must be sorted along the dimensions they will be joined.
// In fact, only one needs to be so sorted.
// This could have instead been done for "model.fst" when it was created.
ArcSort(input, OLABEL_COMPARE);
ArcSort(model, ILABEL_COMPARE);
// Container for composition result.
VectorFstClass result(input->ArcType());
// Create the composed FST.
Compose(*input, *model, &result);
// Just keeps the output labels.
Project(&result,  PROJECT_OUTPUT);
```

## Fst Types

The following non-abstract FST types with file representations are defined in the OpenFst library:

Name Usage Description Registered
vector `VectorFst<A>` General-purpose mutable FST `libfst.{a,so}` %DOX{fst::VectorFst[]}%
const `ConstFst<A>` General-purpose expanded, immutable FST (# arcs < 232) `libfst.{a,so}` %DOX{fst::ConstFst[]}%
constN, N=8,16,64 `ConstFst<A, uintN>` General-purpose expanded, immutable FST (# arcs < 2N) `fst/libfstconst.{a,so}`, `fst/constN-fst.so` %DOX{fst::ConstFst[]}%
compact_string `CompactFst<A, StringCompactor<A>>` Compact, immutable, unweighted, string FST (# arcs < 232) `libfst.{a,so}` %DOX{fst::CompactFst[]}%
compactN_string, N=8,16,64 `CompactFst<A, StringCompactor<A>, uintN>` Compact, immutable, unweighted string FST (# arcs < 2N) `fst/libfstcompact.{a,so}`, `fst/compactN-fst.{a,so}` %DOX{fst::CompactFst[]}%
compact_weighted_string `CompactFst<A, WeightedStringCompactor<A>>` Compact, immutable, weighted, string FST (# arcs < 232) `libfst.{a,so}` %DOX{fst::CompactFst[]}%
compactN_weighted_string, N=8,16,64 `CompactFst<A, WeightedStringCompactor<A>, uintN>` Compact, immutable, weighted, string FST (# arcs < 2N) `fst/libfstcompact.{a,so}`, `fst/compactN_weighted-fst.{a,so}` %DOX{fst::CompactFst[]}%
compact_acceptor `CompactFst<A, AcceptorCompactor<A>>` Compact, immutable, weighted FSA (# arcs < 232) `libfst.{a,so}` %DOX{fst::CompactFst[]}%
compactN_acceptor, N=8,16,64 `CompactFst<A, AcceptorCompactor<A>, uintN>` Compact, immutable, weighted FSA (# arcs < 2N) `fst/libfstcompact.{a,so}`, `fst/compactN_acceptor-fst.{a,so}` %DOX{fst::CompactFst[]}%
compact_unweighted `CompactFst<A, UnweightedCompactor<A>>` Compact, immutable, unweighted FST (# arcs < 232) `libfst.{a,so}` %DOX{fst::CompactFst[]}%
compactN_unweighted N=8,16,64 `CompactFst<A, UnweightedCompactor<A>, uintN>` Compact, immutable, unweighted FST (# arcs < 2N) `fst/libfstcompact.{a,so}`, `fst/compactN_unweighted-fst.{a,so}` %DOX{fst::CompactFst[]}%
compact_unweighted_acceptor `CompactFst<A, UnweightedAcceptorCompactor<A>>` Compact, immutable, unweighted FSA (# arcs < 232) `libfst.{a,so}` %DOX{fst::CompactFst[]}%
compactN_unweighted_acceptor, N=8,16,64 `CompactFst<A, UnweightedAcceptorCompactor<A>, uintN>` Compact, immutable, unweighted FSA (# arcs < 2N) `fst/libfstcompact.{a,so}`, `fst/compactN_unweighted_acceptor-fst.{a,so}` %DOX{fst::CompactFst[]}%
ilabel_lookahead `{Std,Log}ILabelLookAheadFst` Immutable FST with input label lookahead matcher `fst/libfstlookahead.{a,so}`, `fst/ilabel_lookahead-fst.{a,so}`
olabel_lookahead `{Std,Log}OLabelLookAheadFst` Immutable FST with output label lookahead matcher `fst/libfstllookahead.{a,so}`, `fst/olabel_lookahead-fst.{a,so}`
arc_lookahead `{Std,Log}ArcLookAheadFst` Immutable FST with arc lookahead matcher `fst/libfstllookahead.{a,so}`, `fst/arc_lookahead-fst.{a,so}`
ngram `NGramFst<A>` Immutable FST for n-gram language models `fst/libfstngram.{a,so}` %DOX{fst::NGramFst[]}%

These FST types are registered for `StdArc` and `LogArc` in the indicated libraries. The user must register other types themselves for general FST I/O.

Note the libraries other than `libfst.{a,so}` are extensions that must be built and linked separately (to avoid code bloat). For each of these, there is a version that contains all variants of that extension (e.g., `lib/libfstconst.{a,so}`) that should be specified at compile time . Alternatively, there are per variant libraries (e.g. `lib/constN-fst.so`) that will be dynamically loaded into any binary compiled with OpenFst when the `LD_LIBRARY_PATH` (or equivalent) includes e.g. `/usr/local/lib/fst`.

Note `Std{I,O}LabelLookAheadFst`, despite its name, uses the `LogWeight::Plus()` during weight-pushing in composition (only). This choice was made for reasons of efficiency and convenience; it can circumvented by changing the accumulator %DOX{fst::FastLogAccumulator[]}% used.

Non-abstract FST types without file representations include the on-the-fly Fst operations and the following:

Name Description
`EditFst<A>` Wraps an `ExpandedFst` as a `MutableFst`, sharing non-mutated components. %DOX{fst::EditFst[]}%
You can convert to a non-abstract FST Type `F<A>` by calling its `F<A>(const Fst<A> &)` constructor from C++ or the `fstconvert -fst_type=Fname` shell-level command (when there is a file representation).

Lookahead matchers are matchers that implement additional functionality to allow looking-ahead along paths. When used in combination with a lookahead filter in composition, this can result in considerable efficiency improvements. See Cyril Allauzen, Michael Riley and Johan Schalkwyk, "Filters for Efficient Composition of Weighted Finite-State Transducers", Proceedings of the Fifteenth International Conference on Implementation and Application of Automata, (CIAA 2010), Winnipeg, MB.

The matcher interface is augmented with the following methods:

```template <class F>
public:
typedef F FST;
typedef F::Arc Arc;
typedef typename Arc::StateId StateId;
typedef typename Arc::Label Label;
typedef typename Arc::Weight Weight;

// Required constructors.

Below are methods for looking ahead for a match to a label and
more generally, to a rational set. Each returns false if there is
definitely not a match and returns true if there possibly is a match

// LABEL LOOKAHEAD: Can 'label' be read from the current matcher state
// after possibly following epsilon transitions?

// arbitrary rational set of strings, specified by an FST and a state
// from which to begin the matching. If the lookahead FST is a
// transducer, this looks on the side different from the matcher
// 'match_type' (cf. composition).

// Are there paths P from 's' in the lookahead FST that can be read from
// the cur. matcher state?
bool LookAheadFst(const Fst<Arc>& fst, StateId s);

// Gives an estimate of the combined weight of the paths P in the
// A trivial implementation returns Weight::One(). Non-trivial
// implementations are useful for weight-pushing in composition.

// Is there is a single non-epsilon arc found in the lookahead FST
// that begins P (after possibly following any epsilons) in the last
// call LookAheadFst? If so, return true and copy it to '*arc', o.w.
// return false. A trivial implementation returns false. Non-trivial
// implementations are useful for label-pushing in composition.

// Optionally pre-specifies the lookahead FST that will be passed
// to LookAheadFst() for possible precomputation. If copy is true,
// then 'fst' is a copy of the FST used in the previous call to
// this method (useful to avoid unnecessary updates).
void InitLookAheadFst(const Fst<Arc>& fst, bool copy = false);
};
```

The following lookahead matchers are defined in the OpenFst library:

Name Description
`ILabelLookAheadMatcher` Look-ahead to first non-epsilon input label on a path %DOX{fst::LabelLookAheadMatcher[]}%
`OLabelLookAheadMatcher` Look-ahead to first non-epsilon output label on a path %DOX{fst::LabelLookAheadMatcher[]}%
`ArcLookAheadMatcher` Look-ahead to first transition on a path %DOX{fst::ArcLookAheadMatcher[]}%

There are FST types that are provided with these matchers. When these are used in composition, no special options need to be passed; the appropriate matcher and filter are selected automatically.

The ilabel (olabel) lookahead matcher has some special properties. It currently requires that there are no input (output) epsilon cycles. Further, it may relabel the input (output) alphabet in order to efficiently look-ahead. The class `LabelLookAheadRelabeler` (in `<fst/lookahead-matcher.h>`) can be used to obtain the mapping between the old and new alphabet (`LabelLookAheadRelabeler::RelabelPairs`) and to relabel and sort other FSTs with the new labeling to make them suitable for composition (`LabelLookAheadRelabeler::Relabel`). Alternatively, the flag `--save_relabel_ipairs` (`--save_relabel_opairs`) can be used to send the relabeling information to a file when the lookahead matcher is constructed (useful when `fstconvert` is used to create a lookahead FST from the command line).

## Matchers

Matchers can find and iterate through requested labels at FST states; their principal use is in composition matching. In the simplest form, these are just a search or hash keyed on labels. More generally, they may implement matching special symbols that represent sets of labels such as ρ (rest), σ (all) or φ (fail), which can be used for more compact automata representations and faster matching.

The Matcher interface is:

```// Specifies matcher action.
enum MatchType {
MATCH_INPUT, // Match input label.
MATCH_OUTPUT, // Match output label.
MATCH_NONE, // Match nothing.
MATCH_UNKNOWN, // Match type unknown.
};```

```template <class F>
class SomeMatcher {
public:
typedef F FST;
typedef F::Arc Arc;
typedef typename Arc::StateId StateId;
typedef typename Arc::Label Label;
typedef typename Arc::Weight Weight;

// Required constructors.
SomeMatcher(const F &fst, MatchType type);
SomeMatcher(const SomeMatcher &matcher);

// Returns the match type that can be provided (depending on
// compatibility of the input FST). It is either
// the requested match type, MATCH_NONE, or MATCH_UNKNOWN.
// If 'test' is false, a constant time test is performed, but
// MATCH_UNKNOWN may be returned. If 'test' is true,
// a definite answer is returned, but may involve more costly
// computation (e.g., visiting the Fst).
MatchType Type(bool test) const;

// Specifies the current state.
void SetState(StateId s);

// This finds matches to a label at the current state.
// Returns true if a match found. kNoLabel matches any
// 'non-consuming' transitions, e.g., epsilon transitions,
// which do not require a matching symbol.
bool Find(Label label);

// These iterate through any matches found:
// No more matches.
bool Done() const;
// Current arc (when !Done)
const A& Value() const;
// Advance to next arc (when !Done)
void Next();

// Indicates preference for being the side used for matching
// in composition/intersection.
ssize_t Priority(StateId s);

// Return matcher FST.
const F& GetFst() const;

// This specifies the known Fst properties as viewed from this
// matcher. It takes as argument the input Fst's known properties.
uint64 Properties(uint64 props) const;
};```

Name Description
`SortedMatcher` Binary search on sorted input %DOX{fst::SortedMatcher[]}%
`PhiMatcher<M>` φ-symbol handling; templated on underlying matcher %DOX{fst::PhiMatcher[]}%
`RhoMatcher<M>` ρ-symbol handling; templated on underlying matcher %DOX{fst::RhoMatcher[]}%
`SigmaMatcher<M>` σ-symbol handling; templated on underlying matcher %DOX{fst::SigmaMatcher[]}%
`ExplicitMatcher<M>` Suppresses any implicit matches of non-consuming labels %DOX{fst::ExplicitMatcher[]}%
`MultiEpsMatcher<M>` Treats specified non-0 labels as non-consuming labels (in addition to 0) %DOX{fst::MultiEpsMatcher[]}%

`SortedMatcher` expects the underlying FST be sorted on the appropriate side. `Find(0)` matches any epsilons on the underlying FST explicitly (as if they were any other symbol) but also returns an implicit self-loop (namely `Arc(kNoLabel, 0, Weight::One(), current_state)` if the `match_type` is `MATCH_INPUT` and `Arc(0, kNoLabel, Weight::One(), current_state)` if the `match_type` is `MATCH_OUTPUT`); in other words, an epsilon matches at every state without moving forward on the matched FST, a natural interpretation. This behavior implements epsilon-transition handling in composition, or, more generally, a 'non-consuming' match as with the `MultiEpsMatcher` (with `kNoLabel` informing composition of such a match). A composition filter determines which of these epsilon transitions are ultimately accepted. Any matcher used in composition and related algorithms must implement these implicit matches for correct epsilon handling. In some other uses, the implicit matches may not be needed. In that case, an `ExplicitMatcher` can be used to conveniently suppress them (or the user can recognize the `kNoLabel` loop and skip them).

The special symbols referenced above behave as described in this table:

 Consumes no symbol Consumes symbol ε σ φ ρ

The ε symbol is assigned label `0` by convention. The numeric label of the other special symbols is determined by a constructor argument to their respective matchers.

The ρ, σ and φ matchers augment the functionality of their underlying template argument matcher. In this way, matchers can be cascaded (with special symbol precedence determined by the order).

A design choice for these matchers is whether to remove the special symbol in the result (used for the ρ, σ, and φ matchers) or return it (used for epsilon-handling). The first case is equivalent to (but more efficient than) applying special-symbol removal prior to composition (c.f., epsilon removal). This case requires that only one of the FSTs in composition contain such symbols for any paired states. The second case requires well-defined semantics and that composition proper identify and handle any non-consuming symbols on each FST. (The result of `Find(kNoLabel)` identifies on one FST, while the matcher's returning a `kNolabel` loop handles the other, both described above.)

The template `Matcher<F>` selects the pre-designated matcher for `Fst` type `F`; it is typically `SortedMatcher`. Composition uses this matcher by default. It can be changed by using the version of `ComposeFst` that accepts `ComposeFstOptions`. Note two matchers (usually of the same C++ type but different `MatchType`) are used in composition -- one for each FST. Whether actual match queries are performed on one or both FSTs depends on the matcher constructor arguments, the matcher capabilities (queried by `Type()`) and composition itself.

An example access of an FST's matcher is here. An example use of a ρ matcher in composition is here; σ and φ matcher usage is similar.

## Mutable Fsts

A `MutableFst` %DOX{fst::MutableFst[]}% is an ExpandedFst that has additional methods that specifiy how to set the start state, final weights, properties and the input and output symbols, how to add and delete states and arcs, as well as methods to copy and read the mutable FST. In particular, a `MutableFst` class has the interface:

```template <class A>
class MutableFst : public ExpandedFst<class A> {
public:
typedef A Arc;
typedef typename A::StateId StateId;
typedef typename A::Weight Weight;

// Set the initial state
virtual void SetStart(StateId) = 0;
// Set the initial state
virtual void SetFinal(StateId, Weight) = 0;
// Set property bits wrt mask
virtual void SetProperties(uint64 props, uint64 mask) = 0;
// Add a state, return its ID
// Add an arc to state
virtual void AddArc(StateId, const A &arc) = 0;
// Delete some states
virtual void DeleteStates(const vector<StateId>&) = 0;
// Delete all states
virtual void DeleteStates() = 0;
// Delete some arcs at state
virtual void DeleteArcs(StateId, size_t n) = 0;
// Delete all arcs at state
virtual void DeleteArcs(StateId) = 0;
// Get a copy of this MutableFst
virtual MutableFst<A> *Copy() const = 0;
// Read an MutableFst from an input stream; returns NULL on error
// Read an MutableFst from a file; return NULL on error
// Empty filename reads from standard input
// Set input label symbol table; NULL signifies not unspecified
virtual void SetInputSymbols(const SymbolTable* isyms) = 0;
// Set output label symbol table; NULL signifies not unspecified
virtual void SetOutputSymbols(const SymbolTable* osyms) = 0;
};
```

`MutableFst` is an abstract class (note the pure virtual methods). An example is `VectorFst` %DOX{fst::VectorFst[]}%.

The companion mutable arc iterator class provides access to and modification of the transitions of the FST

## Natural Orders

The natural order ≤ associated with a semiring is defined as a ≤ b iff a ⊕ b = a. In the OpenFst library, we define the strict version of this order as:

```template <class W>
NaturalLess() {
bool operator()(const W &w1, const W &w2) const {
return (Plus(w1, w2) == w1) && w1 != w2;
}
};
```

An order is left monotonic w.r.t a semring iff a ≤ b ⇒ ∀c, c ⊕ a ≤ c ⊕ b and c ⊗ a ≤ c ⊗ b; right monotonic is defined similarly. An order is negative iff 10.

The natural order is a left (right) monotonic and negative partial order iff the semiring is idempotent and left (right) distributive. It is a total order iff the semiring has the path property. See Mohri, "Semiring Framework and Algorithms for Shortest-Distance Problems", Journal of Automata, Languages and Combinatorics 7(3):321-350, 2002.

This is the default total order (under the requirements above) that we use for the shortest path and pruning algorithms. This order is the natural one to use given that it generally needs to be total, monotonic and. negative: total so that all weights can be compared, monotonic so there is a practical algorithm, and negative so that the "free" weight 1 is preferred to the "disallowed" weight 0.

## Operation Options

Many FST operations have versions that accept options, especially option structures, that have not been documented in this Wiki for brevity other than to mention some of the parameters that can be changed. For example, most of the delayed Fsts have constructors that accept options that control caching behavior.

Here is an example that selects minimal caching and the rho matcher (for fst2 ρ's) in composition::

```typedef RhoMatcher< SortedMatcher<StdFst> > RM;

ComposeFstOptions<StdArc, RM> opts;
opts.gc_limit = 0;
opts.matcher1 = new RM(fst1, MATCH_NONE, kNoLabel);
opts.matcher2 = new RM(fst2, MATCH_INPUT, SomeRhoLabel);

StdComposeFst cfst(fst1, fst2, opts);
```

Follow the links to the code under each operation's documentation for the specific details.

## Properties

Each `Fst` has associated with it a set of stored properties that assert facts about it. These are queried in an FST with the `Properties()` method and set in a `MutableFst` with the `SetProperties()` method. OpenFst library operations use these properties to optimize their performance. OpenFst library operations and mutable FSTs attempt to preserve as much property information in their results as possible without significant added computation.

Some properties are binary - they are either true or false. For each such property, there is a single stored bit that is set if true and not set if false. The binary `Fst` properties are:

Name Description
`kError` an error was detected while constructing/using the FST
`kExpanded` Is an ExpandedFst
`kMutable` Is a MutableFst

Other properties are trinary - they are either true, false or unknown. For each such property, there are two stored bits; one is set if true, the other is set if false and neither is set if unknown.

Type Name Description
Acceptor `kAcceptor` Input and output label are equal for each arc
`kNotAcceptor` Input and output label are not equal for some arc
Accessible `kAccessible` All states reachable from the initial state
`kNotAccessible` Not all states reachable from the initial state
`kCoAccessible` All states can reach a final state
`kNotCoAccessible` Not all states can reach a final state
Cyclic `kCyclic` Has cycles
`kAcyclic` Has no cycles
`kInitialCyclic` Has cycles containing the initial state
`KInitialAcyclic` Has no cycles containing the initial state
Deterministic `kIDeterministic` Input labels are unique leaving each state
`kNonIDeterministic` Input labels are not unique leaving some state
`kODeterministic` Output labels are unique leaving each state
`kNonODeterministic` Output labels are not unique leaving some state
Epsilons `kEpsilons` Has input/output epsilons
`KNoEpsilons` Has no input/output epsilons
`kIEpsilons` Has input epsilons
`KNoIEpsilons` Has no input epsilons
`kOEpsilons` Has output epsilons
`KNoOEpsilons` Has no output epsilons
Sorted `kILabelSorted` Input labels sorted for each state
`kNotILabelSorted` Input labels not sorted for each state
`kOLabelSorted` Output labels sorted for each state
`kNotOLabelSorted` Output labels not sorted for each state
`kTopSorted` States topologically sorted
`kNotTopSorted` States not topologically sorted
Weighted `kWeighted` Non-trivial arc or final weights
`kNotWeighted` Only trivial arc and final weights

The call `fst.Properties(mask, false)` returns the stored property bits set in the mask bits; some properties may be unknown. it is a constant-time operation. The call `fst.Properties(mask, true)` returns the stored property bits set in the mask bits after computing and updating any of those set in the mask that are unknown. It is a linear-time (O(V + E)) operation if any of the requested bits were unknown.

Note `fstinfo --test_properties=false` will show the stored properties bits, while `fstinfo` or `fstinfo --test_properties=true` will compute unknown properties.

## State Iterators

A state iterator %DOX{fst::StateIterator[]}% is used to access the states of an FST. It has the form:

```template <class F>
class StateIterator {
typedef typename F::Arc Arc;
typedef typename Arc::StateId StateId;

public:
StateIterator(const &F fst);
// End of iterator?
bool Done() const;
// Current state ID (when !Done)
StateId Value() const;
// Advance to next state (when !Done)
void Next();
void Reset();
};
```

It is templated on the Fst class `F` to allow efficient specializations but defaults to a generic version on the abstract base Fst class.

See here for conventions that state iterator use must respect.

An example use of a state iterator is shown here.

## State Mappers

State mappers are function objects used by the StateMap operation to transform states. A state mapper has the form:

```// This determines how symbol tables are mapped.
enum MapSymbolsAction {
// Symbols should be cleared in the result by the map.
MAP_CLEAR_SYMBOLS,

// Symbols should be copied from the input FST by the map.
MAP_COPY_SYMBOLS,

// Symbols should not be modified in the result by the map itself.
// (They may set by the mapper).
MAP_NOOP_SYMBOLS
};

class SomeStateMapper {
public:
// Assumes input arc type is A and result arc type is B
typedef A FromArc;
typedef B ToArc;

// Typical constructor.
SomeStateMapper(const Fst<A> &fst);
// Required copy constructor that allows updating Fst argument.
SomeStateMapper(const SomStateMapper &mapper, const Fst<A&ft; *fst = 0);

// Specifies initial state of result
B::StateId Start() const;
// Specifies state's final weight in result
B::Weight Final(B::StateId s) const;

// These methods iterate through a state's arcs in result
// Specifies state to iterator over
void SetState(B::StateId s);
// End of arcs?
bool Done() const;
// Current arc
const B &Value() const;
// Advance to next arc (when !Done)
void Next();

// Specifies input symbol table action the mapper requires (see above).
MapSymbolsAction InputSymbolsAction() const;
// Specifies output symbol table action the mapper requires (see above).
MapSymbolsAction OutputSymbolsAction() const;
// This specifies the known properties of an Fst mapped by this
// mapper. It takes as argument the input Fst's known properties
uint64 Properties(uint64 props) const;
};```

The following state mappers are defined in the OpenFst library:

Name Description
`ArcSumMapper` Sums weights of identically labeled multi-arcs %DOX{fst::ArcSumMapper[]}%
`ArcUniqueMapper` Keeps one of identically labelled and weighted multi-arcs %DOX{fst::ArcUniqueMapper[]}%
`IdentityStateMapper` Maps to self %DOX{fst::IdentityStateMapper[]}%

Another specialized state mapper is used to implement ArcSort.

## State Queues

State queues are used by, among others, the shortest path and shortest distance algorithms and by the Visit operation. A `state queue` has the form:

```template <class StateId>
class SomeQueue {
public:
// Ctr: may need args (e.g., Fst, comparator) for some queues
SomeQueue(...);
// Returns the head of the queue
// Inserts a state
void Enqueue(StateId s);
// Removes the head of the queue
void Dequeue();
// Updates ordering of state s when weight changes, if necessary
void Update(StateId s);
// Does the queue contain no elements?
bool Empty() const;
// Remove all states from queue
void Clear();
};
```

Pre-defined state queues include:

Queue Description
`AutoQueue` Automatically-selected from Fst properties %DOX{fst::AutoQueue[]}%
`FifoQueue` First-In, first-Out %DOX{fst::FifoQueue[]}%
`LifoQueue` Last-In, first-Out %DOX{fst::LifoQueue[]}%
`NaturalAStarQueue` A* (under natural order with provided estimate) %DOX{fst::NaturalAStarQueue[]}%
`NaturalPruneQueue` Pruning meta-queue (within provided threshold under natural order) %DOX{fst::NaturalPruneQueue[]}%
`NaturalShortestFirstQueue` Priority (least weight under natural order) %DOX{fst::NaturalShortestFirstQueue[]}%
`SccQueue` Component graph top-ordered meta-queue %DOX{fst::SccQueue[]}%
`StateOrderQueue` State-ID ordered %DOX{fst::StateOrderQueue[]}%
`TopOrderQueue` Topologically ordered %DOX{fst::TopOrderQueue[]}%

Some queues accept arc filters to control which transitions are explored.

## State Tables

State tables determine the bijective mapping between state tuples (e.g. in composition triples of two FST states and a composition filter state) and their corresponding state IDs. They are classes, templated on state tuples, of the form:

```template <class T>
class SomeStateTable {
typedef typename T StateTuple;

// Required constructors.
SomeStateTable();
// Lookup state ID by tuple. If it doesn't exist, then add it.
StateId FindState(const StateTuple &);
// Lookup state tuple by state ID.
const StateTuple<StateId> &Tuple(StateId) const;
};
```

A state tuple has the form:

```template <class S>
struct SomeStateTuple {
typedef typename S StateId;

// Required constructor.
SomeStateTuple();
// Data
...
};
```

A specific state tuple is a `ComposeStateTuple` that has data members `StateId state_id1`, `StateId state_id2`, and `FilterState filter_state`.

The following state tables are defined in the OpenFst library:

Name Description
`HashStateTable` Hash map implementation %DOX{fst::HashStateTable[]}%
`CompactHashStateTable` Hash set implementation %DOX{fst::CompactHashStateTable[]}%
`VectorStateTable` Vector implementation %DOX{fst::VectorStateTable[]}%
`VectorHashStateTable` Vector and hash set implementation %DOX{fst::VectorHashStateTable[]}%
`ErasableStateTable` Deque implementation - permits erasures %DOX{fst::ErasableStateTable[]}%

Different state tables provide different time and space tradeoffs for applications.

Composition state tables are defined using state tables with `ComposeStateTuple`. They are the principal data structure used by composition other than the result cache.

The following composition state tables are defined in the OpenFst library:

Name State Table Description
`GenericComposeStateTable` `CompactHashStateTable` General-purpose choice %DOX{fst::GenericComposeStateTable[]}%
`ProductComposeStateTable` `VectorStateTable` Efficient when the composition state space is densely populated %DOX{fst::ProductComposeStateTable[]}%
`StringDetComposeStateTable` `VectorStateTable` Efficient when FST1 is a string and FST2 is deterministic %DOX{fst::StringDetComposeStateTable[]}%
`DetStringComposeStateTable` `VectorStateTable` Efficient when FST1 is deterministic and FST2 is a string %DOX{fst::DetStringComposeStateTable[]}%
`EraseableComposeStateTable` `ErasableStateTable` Allows composition state tuple erasure %DOX{fst::ErasableComposeStateTable[]}%

`GenericComposeStateTable` is the default composition state table. It can be changed by using the version of `ComposeFst` that accepts `ComposeFstOptions`.

## Symbol Tables

Symbol tables store the bijective mapping between textual labels, used in reading and printing an FST textual file, and their integer assignment, used in the FST's internal representation. Symbol tables are usually read in with fstcompile, can be stored by the FST, and used to print out the FST with fstprint,. Here are a examples of symbol table manipulation:

```// Various ways to reading symbol tables
SymbolTable *isyms = fst->InputSymbolTable();
SymbolTable *osyms = fst->OutputSymbolTable();

// Adding and accessing symbols and keys
int64 key = syms->Find("kumquat");
string symbol = syms->Find(7);

// Various ways of writing symbol tables
fst->SetInputSymbols(isyms);
fst->SetOutputSymbols(osyms);
fst->Write("some.fst"):

syms->WriteText("some.syms");
```

## User-defined Fst Arcs and Weights

A user may define his own weight type so long as it meets the necessary requirements.

A user may define his own arc type so long as has the right form. Some Fst I/O with new arc types requires registration.

## Visitors

The simplest way to traverse an FST is in state order using a state iterator.

A very general traversal method is to use:

```Visit(fst, visitor, queue);
```

where the `visitor` object specfies the actions taken in the traversal while the state queue object specifies the traversal order. A `visitor` has the form:

```// Visitor Interface - class determines actions taken during a visit.
// If any of the boolean member functions return false, the visit is
// aborted by first calling FinishState() on all unfinished (grey)
// states and then calling FinishVisit().

template <class Arc>
class SomeVisitor {
public:
typedef typename Arc::StateId StateId;

SomeVisitor(T *return_data);
// Invoked before visit
void InitVisit(const Fst<Arc> &fst);
// Invoked when state discovered (2nd arg is visitation root)
bool InitState(StateId s, StateId root);
// Invoked when arc to white/undiscovered state examined
bool WhiteArc(StateId s, const Arc &a);
// Invoked when arc to grey/unfinished state examined
bool GreyArc(StateId s, const Arc &a);
// Invoked when arc to black/finished state examined
bool BlackArc(StateId s, const Arc &a);
// Invoked when state finished
void FinishState(StateId s);
// Invoked after visit
void FinishVisit();
};
```

While a depth-first search can be implemented using `Visit()` with the `LifoQueue()`, it is often better to use the more specialized `DFSVisit()` in <fst/dfs-visit.h> since it is somewhat more space-efficient and the specialized visitor interface described there has additional funcitionality for a DFS.

Pre-defined FST visitors include:

Visitor Type Description
`CopyVisitor` Visit Copies in a queue-specified order %DOX{fst::CopyVisitor[]}%
`SccVisitor` DfsVisit Finds strongly-connected components, accessibility and coaccessibility %DOX{fst::SccVisitor[]}%
`TopOrderVisitor` DfsVisit Finds topological order %DOX{fst::TopOrderVisitor[]}%

The visit operations optionally accept arc filters to control which transitions are explored.

## Weights

A `Weight` is a type that is used to represent the cost of taking transitions in an FST.

The following basic weight templates are defined in the OpenFst library:

Semiring Name Set
(Plus)

(Times)
0
(Zero)
1
(One)
Notes
Expectation `ExpectationWeight<W1, W2>` W1 X W2 W1 X ⊕W2 expectation (0W1,0W2) (1W1,0W2)   %DOX{fst::ProductWeight[]}%
Lexicographic `LexicographicWeight<W1, W2>` W1 X W2 min W1 X ⊗W2 (0W1,0W2) (1W1,1W2) min: lexicographic order w.r.t.
`W1` and `W2` natural orders
%DOX{fst::LexicographicWeight[]}%
Log `LogWeightTpl<T>` [-∞, ∞] -log(e-x + e-y) + 0 `T`: floating point %DOX{fst::LogWeightTpl[]}%
MinMax `MinMaxWeightTpl<T>` [-∞, ∞] min max -∞ `T`: floating point %DOX{fst::MinMaxWeightTpl[]}%
Power `PowerWeight<W, n>` Wn Wn Wn 0Wn 1Wn   %DOX{fst::PowerWeight[]}%
Product `ProductWeight<W1, W2>` W1 X W2 W1 X ⊕W2 W1 X ⊗W2 (0W1,0W2) (1W1,1W2)   %DOX{fst::ProductWeight[]}%
SignedLog `SignedLogWeightTpl<T>` {-1,1} X [-∞, ∞] signed_log (*,+) (1, ∞) (1, 0) `T`: floating point %DOX{fst::SignedLogWeightTpl[]}%
SparsePower `SparsePowerWeight<W>` Wn Wn Wn 0Wn 1Wn `n`: arbitrary %DOX{fst::SparsePowerWeight[]}%
String `StringWeight<L, STRING_LEFT>` L* ∪ {∞} longest com. prefix ε `L`: signed integral %DOX{fst::StringWeight[]}%
`StringWeight<L, STRING_RIGHT>` L* ∪ {∞} longest com. suffix ε `L`: signed integral %DOX{fst::StringWeight[]}%
Tropical `TropicalWeightTpl<T>` [-∞, ∞] min + 0 `T`: floating point %DOX{fst::TropicalWeightTpl[]}%

The following weight types have been defined in the OpenFst library in terms of the above:

Name Type
`GallicWeight<L, W, S>` `ProductWeight<StringWeight<L, S>, W>`
`LogWeight` `LogWeightTpl<float>`
`Log64Weight` `LogWeightTpl<double>`
`MinMaxWeight` `MinMaxWeightTpl<float>`
`SignedLogWeight` `SignedLogWeightTpl<float>`
`SignedLog64Weight` `SignedLogWeightTpl<double>`
`TropicalWeight` `TropicalWeightTpl<float>`

Composite weights, such as `ProductWeight` and `LexicographicWeight`, can use command line flags to control their textual formatting. `FLAGS_fst_weight_separator` is printed between the weights (default: `","`). `FLAGS_fst_weight_parentheses` (default: `""`) brackets the weight; if you create nested composite weights, they need to be printed with non-empty brackets (e.g. `"()"`) to ensure correct parsing if read back in. These affect only textual (not binary) I/O.