and if I don’t see anyone finding bugs, I tend to believe the project is o.k. or gets ignored, which is fine for me in either way. Do you intend to use it seriously?

]]>i) There is a an edge (a,b) such that P(u,a) is true and P(b,v) is true.

]]>iii) The label of u and the label of v sum to zero, and there is an edge (u,v).

]]>Define P(u,v) to be the predicate “there is a valid path from u to v”. Then P(u,u) is false for all u.

And, isn’t it the following claim true?

Claim: for u != v, P(u,v) is true if and only if one of the following two conditions holds?

i) There is a vertex w such that P(u,w) is true and P(w,v) is true.

ii) The label of u and the label of v sum to zero, and there are edges (u,a) and (b,w) such that P(a,b) is true.

If indeed this claim holds, it gives you a dynamic programming algorithm running in time, say, O(N^4). You can probably improve that.

]]>Given that Bernard Stepien’s presentation was given at a TTCN conference, it is quite natural that it aims to highlight benefits of TTCN. The circles are small, and he’s more or less a semi-regular presenter there. It is sad that the presentation is so clearly constructed purely for the purpose of making TTCN-3 look good, without any real attempt at a sound academic-quality comparison. Or maybe its just incompetence.

It is good to try & understand the differences though, so this kind of comparisons serve a purpose regardless 😀

But getting into categorical argument about special-purpose testing language vs. using a general-purpose language for testing would be just plain silly. It all depends on purpose, context and requirements. For example, it would be silly to use TTCN-3 for direct testing of Python programs, but I would rather pick TTCN-3 for low-level telecommunications protocol conformance and interoperability testing any day. The testing-specific features built right into TTCN-3 are particularly useful for such purposes and contexts, and while they could be replicated in Python, the implementations would always be less elegant.

]]>I will definitely update my implementation of univset based on this. Coincidentally I’ve just revised Langscape’s lexer and included set literals as well as pattern such as complement pattern ~{} expressing the same as the regexp dot. The inclusion of the __invert__ method matches the semantics perfectly. The algebraic equations look so nice that I could even imagine that some people on python.ideas find this cute and univset would be a great addition to the Python core.

]]>