For what it's worth, the ordering reported is consistent with xfst: xfst[0]: read regex a; 116 bytes. 2 states, 1 arc, 1 path. # push a xfst[1]: read regex b; 116 bytes. 2 states, 1 arc, 1 path. # push b xfst[2]: concatenate # concatenate the two 144 bytes. 3 states, 2 arcs, 1 path. xfst[1]: print net Sigma: a b Size: 2 Net: 811AE50 Flags: deterministic, pruned, minimized, epsilon_free, loop_free Arity: 1 s0: b -> s1. # result has b left of a s1: a -> fs2. fs2: (no arcs) Dale Gerdemann Stephan Kanthak wrote:

Hi Roy,

On Thursday 05 May 2005 16:59, Roy Tromble wrote:

...

I noticed yesterday that the Fsa command-line tool's concat operator works backward from what I expected. It puts the transducer at the top of the stack (what I think of as right-most) at the front of the concatenated transducer. Is this the intended behavior? It seems especially strange since for the operations that take two transducers as arguments, second_ is defined as the top of the stack, and first_ as the position below it.

You are right, the order is wrong. There is an upcoming release in progress and I will fix it.

Stephan

_______________________________________________ fsa mailing list fsa@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/fsa