caleb531/automata

Unexpected behavior when directly instantiating NFA

Closed this issue · 2 comments

When working through the examples I tried instantiating some NFAs as we had previously done for DFAs, and the same example inputs aren't valid. After trying a few more cases, it looks to me like NFAs will only accept state identifiers one character long, and more specifically they seem to be truncating end states to the first character during instantiation. For example, this example worked for a DFA:

my_dfa = DFA(
    states={'00', '11', '22'},
    input_symbols={'0', '1'},
    transitions={
        '00':{'0':'00', '1':'11'},
        '11':{'0':'00', '1':'22'},
        '22':{'0':'22', '1':'11'}
    },
    initial_state='00',
    final_states={'11'}
)

but not for an NFA:

my_nfa = NFA(
    states={'00', '11', '22'},
    input_symbols={'0', '1'},
    transitions={
        '00':{'0':'00', '1':'11'},
        '11':{'0':'00', '1':'22'},
        '22':{'0':'22', '1':'11'}
    },
    initial_state='00',
    final_states={'11'}
)

This latter one reports InvalidStateError: end state 0 for transition on 00 is not valid

Acknowledging that I'm out of my depth subject-matter-wise, this looks like a bug to me. I'm running the latest command line version in python 3.12.3 on a mac.

This is expected behavior. The transition dictionary for NFAs ends on a set of states rather than a single state (the weird error message is because it's iterating through the string for the state name the way it would a set). The reason for this has to do with how these objects are defined mathematically. This difference is present in the API documentation, but we can add an example of an NFA defined by hand to the first example.

To directly create an NFA equivalent to an input DFA, you can use the NFA.from_dfa method.

Related to review: pyOpenSci/software-submission#152

Closing this issue as per @eliotwrobson's comment, this is the expected behavior.