better encoding for parity acceptance

[adl]

I'm implementing some support for generating and recognizing parity acceptance conditions, and I don't like the encoding currently suggested in the specifications:

acc-name: parity min even 5
Acceptance: 5 Inf(0) | (Fin(0)&Fin(1)&Inf(2)) | (Fin(0)&Fin(1)&Fin(2)&Fin(3)&Inf(4))

I would prefer this to be

acc-name: parity min even 5
Acceptance: 5 Inf(0) | (Fin(1)&Inf(2)) | (Fin(1)&Fin(3)&Inf(4))

The two formulas are logically equivalent, but the second

• is an irredundant sum of products,
• does not use the same set number in both Fin and Inf primitves.

In particular, I have found the latter point to be important in several algorithms. I can think of at least three algorithms in Spot where either I have special cases to handle acceptance with sets that are both used as Inf and Fin, or the algorithm is simply requires disjoint Fin/Inf numbers as a prerequisite. (My typical simple "horror case" is Acceptance: 2 (Fin(0)&Inf(1)) | (Inf(0)&Fin(1)) which basically encodes Inf(0) xor Inf(1).)

What do you think? Can I change the parity examples to use the irredundant encoding?

[xblahoud]

I like the suggestion. It makes the acceptance shorter and I can't see any disadvantages.

[strejcek]

I agree, please change it.

[adl]

I've made a patch on branch adl/42, but I would like Joachim's opinion before we merge it, as I think he is the only producer of Parity automata currently.

[JanKretinsky]

I'm also fine with your suggestion

[kleinj]

Fine by me. Currently, jhoafparser does not check for the canonical Acceptance expression for parity, I'll add that.

Should we add the canonical expressions for 'min odd' and 'max even' to the format document as well, just to be extra clear what's expected?

[adl]

I've added examples for parity min odd 6 and parity max even 5. Can you double check and merge if you are happy with it?