Improve label handling/displaying for locations

[ariadne-cps]

Improve label handling/displaying for locations

[lgeretti]

Original comment by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

---

Ok, we can roll back to the previous two classes then.

[lgeretti]

Original comment by Pieter Collins (Bitbucket: pietercollins, GitHub: pietercollins)

---

I think we should keep the current HybridAutomaton class, since we can a) use multiple discrete variables to describe a single location, and b) even use different variables for different locations. I think this functionality is good enough to keep. We can definitely reinstate AtomicHybridAutomaton for the semantics you describe.

[lgeretti]

Original comment by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

---

Would using AtomicHybridAutomaton only be ok with you? We could provide an abstract HybridAutomatonBase that comes from HybridAutomaton, and then rename AtomicHybridAutomaton into HybridAutomaton.

If AtomicHybridAutomaton is not enough for all your use-cases, we should allow alternative methods, rather than alternative implementations.

[lgeretti]

Original comment by Pieter Collins (Bitbucket: pietercollins, GitHub: pietercollins)

---

A rationale for keeping (discrete) variable names separate from the automaton name is that a component automaton may have several discrete variables, and we should support this use-case too.

We could reinstate AtomicHybridAutomaton, possibly refactoring so that it does not expose the HybridAutomaton methods. (Alternatively, and more simply, we just override/delete the HybridAutomaton methods.)

Alternatively, we could force every HybridAutomaton to define its discrete variables on construction, and just use these, though this is less flexible in the case that some discrete variables are only needed in some modes.

I also plan to remove the DiscreteLocation(String) and DiscreteLocation(Int) constructors, which create a DiscreteLocation variable with default name "q".

[lgeretti]

Original comment by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

---

Yes, it is very similar to how AtomicHybridAutomaton worked from the user perspective.
I'm ok with your reasoning on distinguishable locations, still it does not feel right to be redundant in the definition of transitions and modes. In particular, the need to define the automaton variable with the automaton name, and then again the string variable with the automaton name, feels a bit unwieldy and prompt to user errors. The same goes for locations.

[lgeretti]

Original comment by Pieter Collins (Bitbucket: pietercollins, GitHub: pietercollins)

---

Your proposal seems to be essentially how AtomicHybridAutomaton worked, could you take a look at the old code and see if this is indeed the case?

Currently, a hybrid system is defined by its state variables which can be discrete (String and Integer; though the latter is not really supported now, but could easily be) or continuous (Real). A discrete location is a valuation of discrete variables. Different variables may be used for different locations, but two different locations must be distinguishable i.e. have a common variable with a different value in each. This approach using variables gives a clear and uniform semantics which can be used for atomic/monolithic/composite hybrid automata. The name of a component hybrid automaton is currently not used.

I've considered adding enumerated variables for discrete locations instead of relying on strings, but at the moment it doesn't seem worth the effort.