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

Re: [tlaplus] Aside from WF and SF?

Thank you Stephan. I really need to think it thru, I just can't get it reason out yet in my head. I was wondering if the first formula is weaker than []<><<A>>_v, is it stronger than SF_v(A)?

Hi Andrew, you are right....my derivation got short cut too much between = and =>. I am not sure if another derivation attempt of mine below makes sense or not.

[](<>[]P => <>Q)
[](<>[]P => <>Q) => ([]<>[]P => []<>Q)
                                     <>[]P => []<>Q
                              ~<>[]P \/ []<>Q
                                      []~[]P \/ []<>Q
[](~[]P \/ <>Q)  <=       []~[]P \/ []<>Q
[]([]P => <>Q)   <=>  WF
                            =    WF

Thanks and best regards,
Chris (Zitro)





On Thursday, November 13, 2025 at 12:15:12 PM UTC-8 Stephan Merz wrote:
I meant []~ENABLED. As soon as the action is enabled at some point, your condition requires <<A>>_v to eventually occur. 

Stephan

On 13 Nov 2025, at 19:18, Chris Ortiz <zitro...@xxxxxxxxx> wrote:

Hi Stephan,

Thank you. Do you mean never enabled (which I think is []~ENABLED) , or it should be not always enabled (which is ~[]ENABLED)?

Best regards,
Chris (Zitro)

On Thursday, November 13, 2025 at 9:44:15 AM UTC-8 Chris Ortiz wrote:
Thank you Andrew and Stephan. I was thinking the same way but I don't trust my intuition as I don't know how to formally prove it.

For the second formula.
[](<>[]ENABLED <<A>>_v => <><<A>>_v)
[]<>[]ENABLED <<A>>_v => []<><<A>>_v
<>[]ENABLED<<A>>_v => []<><<A>>_v
~<>[]ENABLED<<A>>_v \/ []<><<A>>_v
[]~[]ENABLED<<A>>_v \/ []<><<A>>_v
[](~[]ENABLED<<A>>_v \/ <><<A>>_v)
[]([]ENABLED<<A>>_v => <><<A>>_v) which is WF_v(A)

So it means the second formula is just a tautology of WF_v(A), or equivalent.

For the first formula
[](ENABLED <<A>>_v => <><<A>>_v)
[]ENABLED<<A>>_v => []<><<A>>_v
~[]ENABLED<<A>>_v \/ []<><<A>>_v <--- This is where I mind got short-circuited

As per Andrew, if this is unconditional fairness then this should be equivalent to []<><<A>>_v, for which I don't know how to derive.

Thanks and best regards,
Chris (Zitro)




On Thursday, November 13, 2025 at 8:59:57 AM UTC-8 Andrew Helwer wrote:
Thanks, Stephan! Another interesting question that occurs to me is whether the first formula is equivalent to unconditional fairness, since presumably a step must be enabled before it can be taken. Thus the ENABLED A precondition seems redundant.

Andrew

On Wed, Nov 12, 2025 at 11:34 PM Stephan Merz <stepha...@xxxxxxxxx> wrote:
As Andrew suspects, the second formula is equivalent to weak fairness:

THEOREM
ASSUME NEW ACTION A, NEW STATE v
PROVE WF_v(A) <=> [](<>[]ENABLED <<A>>_v => <><<A>>_v)
BY PTL

Stephan

On 13 Nov 2025, at 01:51, Andrew Helwer <andrew...@xxxxxxxxx> wrote:

[](ENABLED <<A>>_v => <><<A>>_v) is equivalent to []((ENABLED A) ~> <><<A>>_v) which means if an A step is enabled (like at all), eventually it will be taken; moreover, it will also be taken after every time an A step is enabled in the future. This is like an even stronger fairness assumption, but looking through the texts I have it does not seem to be a standard one. The usual next strongest fairness assumption in temporal logic is unconditional fairness, which is just []<><<A>>_v. There are a lot of fairness definitions out there though so I'm sure someone has covered & named it.

For the second one, since P => <>P, it seems to be implied by weak fairness. So it is at most as strong as weak fairness. Is it any weaker than weak fairness? I can't think of how it could be, but then we should be able to rewrite it into weak fairness. And there I am somewhat at a loss.

Andrew

On Wed, Nov 12, 2025 at 4:09 PM Chris Ortiz <zitro...@xxxxxxxxx> wrote:
Hello,

WF_v(A) == []([]ENABLED <<A>>_v => <><<A>>_v) and
SF_v(A) == []([]<>ENABLED <<A>>_v => <><<A>>_v)

Is there

[]( ENABLED <<A>>_v => <><<A>>_v) and
[](<>[]ENABLED <<A>>_v => <><<A>>_v ?

And what could they mean?

Thanks and best regards,
Chris (Zitro)

--
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 visit https://groups.google.com/d/msgid/tlaplus/98c4554e-2498-448c-86fd-ada5308a4c11n%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+u...@xxxxxxxxxxxxxxxx.

--
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.

--
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 visit https://groups.google.com/d/msgid/tlaplus/292f0d2e-3021-44a3-b4e8-1df70431a53en%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 visit https://groups.google.com/d/msgid/tlaplus/900092c4-d004-42fc-a049-5a1036877e1cn%40googlegroups.com.