Gsm v2

[emuskardin]

TODO

add_labeled_sequence aggregates intermediate steps under unknown_output (DataHandler.py:100-110) and, when a later sequence resolves that output, only remaps transitions — the handler data is left alone. So count-based handlers on labeled_sequences split counts across two keys:

labeled: {'a': {<unknown_output>: 1, False: 1}}   vs   io_traces: {'a': {False: 2}}

shadow_pta keeps a stale unknown_output key the same way. Fixing it properly needs a "output resolved" hook on DataHandler (the remap is handler-specific), which is more than a minimal change, so I left it: it's captured as @unittest.expectedFailure in test_gsm_data_handler.py:46 with the cause in a comment. It flips to an unexpected success once fixed.

- GsmAlgorithms.py mealy sentinel leak: run_EDSM(..., automaton_type='mealy') on data that isn't prefix-closed (violates the documented precondition) doesn't raise — it silently produces a MealyMachine with unknown_output's sentinel object as a real transition's output. Low priority since it's already documented as unsupported, but corrupting silently instead of raising seems worth a guard.

Ensure, also in tests / run exaustive that I have added, that DFA and Moore learning works also with non-prefix closed data

[zwergziege]

I can understand why you want a conservative default. An issue I see with having a single NoScore result in NoScore is that it makes non-early scores meaningless if any of the score calculations returns NoScore, but they shouldn't do that anyways. This is probably just an indication that NoScore should be a proper sentinel and init_merge and early verdict computation should be split.

[zwergziege]

if i'm not mistaken, no such overwriting can happen, since promoting does not change the node. there is an issue though that the promotion changes what should be counted as blue node after the partition is applied, but it should be possible to compute that

[zwergziege]

regarding 1: since having counts for non-prefix-closed deterministic data is not all that useful, i suggest simply raising an exception if unknown_output is encountered in the data handler. if somebody really needs it, they can implement it themselves.

regarding 2: i think this behavior is perfectly fine. the classic RPNI version also does not raise on None outputs. a warning maybe.