Create Nft with inverted levels (tapes)

[koniksedy]

This PR introduces:

• Method Nft::invert_levels with tests:
  • Nft::invert_levels creates an Nft where the 1st tape becomes the n-th, the 2nd becomes the (n-1)-th, and so on.
  • (a,b)----a---->(c,d)----b---->(e,f) will become (b,a)----a---->(d,c)----b---->(f,e)
• Method StatePost::get_successors and Delta::get_successors
  • TODO: Remove Delta::post in the future.
• Method Delta::get_transitions_between:
  • Returns a vector of transitions that lead from state_from to state_to
• Method Levels::count:
  • Based on std::count
• Method Nft::num_of_states_with_level:
  • Based on the previous method count

[Adda0]

I merged the PR so we can quickly iterate on transducers. The reviews can come later.

[vhavlena]

Hi, I don't think we are in a such hurry to merge everything. I have at least one thing: rename please invert_levels with invert_tapes. As a transducer user I know about tapes but I have absolutely no idea about levels.

[Adda0]

I have at least one thing: rename please invert_levels with invert_tapes. As a transducer user I know about tapes but I have absolutely no idea about levels.

This is incompatible with the original idea that the base data structure is just an automaton with levels. The fact that is precisely models a transducer if you squint hard enough is basically just a happy accident with this idea. We never use the word tape anywhere in the code except to explain that for transducers, what you know as "tape" is here in Mata a "level". One day in the future, there will be a base class for a general level automaton, which is inherited by NFTs, counter automata, register automaton etc. That means that all the common functionality should adhere to the notion of a level and only specialized functions for each of the automata models should have their own specialized functions. However, in the case of NFTs, the functionality is so similar to the base level automaton that renaming everything to tapes would be highly !counter-productive, in my opinion, not to mention impossible (the class Levels can never be renamed if the class is to be inherited from the base class). The chosen approach was that when you want to work with NFTs in Mata, you just have to learn about Levels as they are everywhere.

Of course, we can discuss if this is a good approach, or not. But as of now, it is the only approach possible to stay in line with in the codebase.

[vhavlena]

I am not talking about the internal representation. It is definitely ok to use levels in the internal representation of undelying autoton structure. But in the top-level API you provide should not imo use level. You provide API for working with transducers. At least for the common operations the naming conventions should be compatible with the rest of the automata world.

[Adda0]

That I can understand. The problem is that there is no internal representation in Mata. The whole Mata is made in such a way that everything is public and one can access (nearly) any member variable or method. That means that if we have the high-level API (shared among the automata models) using tapes, and then 3 lines down you iterate over a delta using levels, it can just never be consistent. Again, it is up for debate whether this is a good compromise or not.

[vhavlena]

Ok, I see. In the light of this, from architecture point of view it is a bit unfortunate that the base class for level automata coincides with transducers. Anyway, I fine with a creation of alias level=tape for transducers in my head.