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

*From*: "c.burge...@xxxxxxxxx" <c.burge.glasgow@xxxxxxxxx>*Date*: Mon, 26 Apr 2021 03:57:43 -0700 (PDT)*Ironport-hdrordr*: A9a23:2rYBaK+qQCtmJKxGqrNuk+F3db1zdoIgy1knxilNYDZSddGVkN3roeQD2XbP+UoscVwDufTFAqmPRnvA6YV4iLN6UIuKcQH6tAKTXeVfxKT4xTmIIVyYysd80uNaf7F6GJnMCzFB/L7HySy5Cctl6MKM8aC2iY7lvgFQZCRrcbwlzgt9E2+gYzpLbSxHH4d8NLf03Ls1mxOEeW4LKv28HGRtZZm2m/TvlIj6JSIAHQIt8gOUjTilgYSKWiSw+jc7f3dxzaw58W7D+jaJm5mLl/m6zx/a2SvX745K8eGRuudrIMCXkMAaJnHNh2+TFf1ccoSYsDo4re2p4lpCqqi8nz4aM85+62zccwiOyHOHqmvd+Q0j5HP4xViTjWGLm72DeBsAB9NFlcZldHLimjQdletx169GxAui2KZ/Nw/Knyj2+rHzJmtXv3ezyEBS99I7vjh1XYcYVb5ctoB3xjI3LL4wWAz/rKQqCvNnAs2Z3utfbF/yVR7kl1gq7tqrUHE+WjqlYmxHgMya1DBKgGt0pnF1+OUv2lkH8pw5R91r/OLZK+BJmdh1P7orRJM4KuEGT866TlbIXAuJCmSPOl7qfZtnB1v977jt4Ls04+muPKYFy5Y/g/36ISxlnF93QE7lBc2Q0JAjyHC9JVmVbHDW08lbo7J5trf/SLeuESrGZkspj9LImYRsPvHm*References*: <d4b24a56-e945-48b4-af19-b8a16872a87dn@googlegroups.com> <862EFD8E-1E6D-43B4-92CD-A707E1081FB1@gmail.com>

Thank you! A number of different approaches to consider then!

On Saturday, April 24, 2021 at 7:36:22 AM UTC+1 Stephan Merz wrote:

If your algorithm does not at all depend on the result of division, you can replace it by a constant parameter Div(_,_). For theorem proving, you should then be able to prove the properties that you are interested in. For model checking, you will still need to provide an instance of that operator, sayDiv(x,y) == 42but you can run TLC with different definitions to become confident that the definition is indeed irrelevant. However, if this is true, it sounds like you could write an even more abstract specification, such as getting rid of variables to which division is applied.If your algorithm depends on certain properties of division but not the precise result you can state those in an ASSUME clause, say,ASSUME \A x,y \in Int : y # 0 => Div(x,y) \in Int /\ Div(x,y) < xStephanOn 23 Apr 2021, at 22:49, christin...@gmail.com <christin...@xxxxxxxxx> wrote:I know that TLA+ does not reason about real numbers, but can we model an algorithm which does ?For example, if the algorithm we want to verify contains a division, and only integer division is supported in TLA+, can we go ahead and model it anyway (if we are interested in other things about it), even though the numerical answer will be wrong? My instinct is that this should not be a problem but I am not 100% sure.--

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+u...@xxxxxxxxxxxxxxxx.

To view this discussion on the web visit https://groups.google.com/d/msgid/tlaplus/d4b24a56-e945-48b4-af19-b8a16872a87dn%40googlegroups.com.

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 view this discussion on the web visit https://groups.google.com/d/msgid/tlaplus/81d0d92a-54a8-4b56-b23f-1e6d38738130n%40googlegroups.com.

**References**:**[tlaplus] Numerical correctness vs logical correctness***From:*christin...@xxxxxxxxx

**Re: [tlaplus] Numerical correctness vs logical correctness***From:*Stephan Merz

- Prev by Date:
**Re: [tlaplus] About WF and SF operators' semantics** - Next by Date:
**[tlaplus] Error with CommunityModules (kSubset)** - Previous by thread:
**Re: [tlaplus] Numerical correctness vs logical correctness** - Next by thread:
**[tlaplus] About WF and SF operators' semantics** - Index(es):