[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*From*: Philip White <philip@xxxxxxxxxxxxx>*Date*: Thu, 14 Feb 2019 11:19:10 -0800*References*: <350F45E9-8039-499E-923A-91B42C4B61CA@mailworks.org> <3F57F908-72B9-4EE2-A3B3-BAF474FCFC09@gmail.com>

Thanks — the clarification about tuples vs. sets was very helpful. I sort of understand what you mean about naming an element with CHOOSE. However, in my spec, I use CHOOSE without caring what item I’m choosing. My goal is to select any item so that later I can check that the item is a member of that set. Is it possible to do this and retain symmetry? — Philip > On Feb 14, 2019, at 12:12 AM, Stephan Merz <stephan.merz@xxxxxxxxx> wrote: > > Hello Philip, > >> I cannot reconcile these two statements. Suppose the original CHOOSE expression gives v1. After the same substitution as in the first quote, the CHOOSE expression gives v3. Is that not "equal to the original expression", in the same way that the tuples above are equal? > > {{v1, v2}, {v1, v3}, {v2, v3}} is not a tuple, but a set (of sets), and sets are unordered. Therefore, {{v3, v2}, {v3, v1}, {v2, v1}} is the same set as the first one. But note that you cannot even write this set unless you have access to the names of its elements. > >> What is unique about CHOOSE that it is "the only TLA+ operator that can produce a non-symmetric expression”? > > A CHOOSE expression allows you to name an element of the set, distinguishing it from the others. > > Suppose we have a constant parameter S, instantiated to the set of model values {v1,v2,v3}, and a definition > > someS == CHOOSE x \in S : TRUE > > Then the expression > > IF s = someS THEN 0 ELSE 42 > > returns 0 for the chosen value but 42 for the others and is therefore not symmetric in S. This shows that S cannot be declared as a symmetry set for a specification that contains these entities. > > The other TLA+ operators do not allow you to name elements of your parameter sets, for example you cannot explicitly build the tuple > > << v1, v2, v3 >> > > which would not be symmetric in S. In contrast, expressions such as > > { seq \in Seq(S) : Len(seq) = 3 } > > i.e., the set of all triples built from S, are symmetric. > > In contrast, replacing the definition of someS with the operator definition > > notS == CHOOSE x : x \notin S > > does not destroy symmetry of the specification with respect to S. In particular, the test > > s = notS > > returns FALSE for all elements of S. > > In summary, symmetry reduction is very helpful for model checking, but deciding if a parameter can be declared as a symmetry set for a given specification can be subtle. > > Regards, > Stephan > > >> On 14 Feb 2019, at 00:49, Philip White <philip@xxxxxxxxxxxxx> wrote: >> >> Hello, TLA enthusiasts, >> >> I'm having trouble understanding when it is safe to use symmetry sets. >> >> This documentation at https://tla.msr-inria.inria.fr/tlatoolbox/doc/model/model-values.html says: >> >>> The expression {{v1, v2}, {v1, v3}, {v2, v3}} is symmetric for the set {v1, v2, v3} -- for example, interchanging v1 and v3 in this expression produces {{v3, v2}, {v3, v1}, {v2, v1}}, which is equal to the original expression. >> >> then it says: >> >>> `CHOOSE x \in {v1, v2, v3} : TRUE` is not symmetric for {v1, v2, v3}. >> >> I cannot reconcile these two statements. Suppose the original CHOOSE expression gives v1. After the same substitution as in the first quote, the CHOOSE expression gives v3. Is that not "equal to the original expression", in the same way that the tuples above are equal? >> >> What is unique about CHOOSE that it is "the only TLA+ operator that can produce a non-symmetric expression”? >> >> Thanks for any insights. >> >> — >> Philip >> >> >> -- >> You received this message because you are subscribed to the Google Groups "tlaplus" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to tlaplus+unsubscribe@xxxxxxxxxxxxxxxx. >> To post to this group, send email to tlaplus@xxxxxxxxxxxxxxxx. >> Visit this group at https://groups.google.com/group/tlaplus. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups "tlaplus" group. > To unsubscribe from this group and stop receiving emails from it, send an email to tlaplus+unsubscribe@xxxxxxxxxxxxxxxx. > To post to this group, send email to tlaplus@xxxxxxxxxxxxxxxx. > Visit this group at https://groups.google.com/group/tlaplus. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "tlaplus" group. To unsubscribe from this group and stop receiving emails from it, send an email to tlaplus+unsubscribe@xxxxxxxxxxxxxxxx. To post to this group, send email to tlaplus@xxxxxxxxxxxxxxxx. Visit this group at https://groups.google.com/group/tlaplus. For more options, visit https://groups.google.com/d/optout.

**Follow-Ups**:**Re: [tlaplus] Symmetry sets***From:*Hillel Wayne

**References**:**[tlaplus] Symmetry sets***From:*Philip White

**Re: [tlaplus] Symmetry sets***From:*Stephan Merz

- Prev by Date:
**[tlaplus] Re: Fumbling Through TLA+** - Next by Date:
**Re: [tlaplus] Symmetry sets** - Previous by thread:
**Re: [tlaplus] Symmetry sets** - Next by thread:
**Re: [tlaplus] Symmetry sets** - Index(es):