Hi Roy,

On Tuesday 31 May 2005 22:54, Roy Tromble wrote:

Fsa seemed to have no way of constructing the cross product of two acceptors, so I wrote a function that would do it.

Right.

I think I must have handled the alphabets wrong, because when I concatenate such a transducer with others, I get arcs with 2147483647 for the label.

Arcs labeled with 2147483647 have invalid label id's. However, compose cannot add them to the automaton on it's own, as it does not leave any field uninitialized and uses only fields from the input automata. So, your observed phenomenon must happen due to one of the preprocessing steps (look at the constructor of ComposeAutomaton) or because the input automata contain InvalidLabelIds already. Neither caching nor sorting may produce InvalidLabelId and mapOutput works only on the intermediate alphabets and arc labels (not on the input and output alphabets and arc labels that are in the result). So they must be in one of the input automata already. I suppose you checked that already, but to be 100% sure about unreported parsing errors, try the following:

fsa automaton1 write - automaton2 write - | grep 2147483647

If this reveils occurances of InvalidLabelId, there must be some unreported parsing error for which I should add some code.

Here's what I did:

crossProduct is a function that maps the output labels of the first transducer and the input labels of the second transducer to epsilon, and then composes them.

To map input labels and output labels to epsilon, I have two different classes extending ModifyAutomaton:

EpsilonInputAutomaton replaces all of the arc input labels with Epsilon, and returns an empty Alphabet from getInputAlphabet.

EpsilonOutputAutomaton does likewise with the outputs.

Is there something obviously wrong with this that should lead to InvalidLabelId (which I think 2147483647 corresponds to) when I concatenate a transducer produced using my crossProduct function?

Sounds ok. I would have implemented it in the same way.

Stephan