hi!
With the aid of SPOT I am developing a counter-example guided synthesizer
in python. See [1] if interested for details.
My question is:
I am trying to parse twa_run in python,
namely, parse the labels of the each step (`spot.impl.step`).
Is there a python way to walk through BDD?
(The label is a simple cube expressed in BDD, and I need to convert it into
my internal structure)
(yes, this is rather a question about python interface for buddy)
(no, that is not feature request:) if not possible, I will simply print the
label and parse the string, that is not crucial)
[1]
The idea is
- guess the model,
- then model check it and get a counter-example
- then encode the counter-example into the "guesser" (which uses an SMT
solver)
thanks,
Ayrat
Dear Spot Team,
Thanks for providing a wonderful tool.
During constructing Buchi automata for LTL, Spot always shows non-determinism automata although I select the "deterministic" item. Would you mind telling me how to construct deterministic automata with Spot? Here is one LTL: !(false R (iusr2_ai3_re13 & (! X (true U iusr2_ai3_re14) | X (true U (iusr2_ai3_re14 & (true U ousr2_ai3_ce8)))))). The following is its automata but non-determinism.
[cid:83ad2cd0-bc60-443c-b387-4bc7953c05d2]
Looking forward to your response.
Kind Regards,
Ruijie
Hi,
I'm using / comparing Spot and other tools in the Rabin to Parity
translation. I have two questions (to ensure my comparison is fair):
1) I want to minimize the input automata using Spot to remove the
effects of preprocessing done by each tool as much as possible. However,
I require that the acceptance condition remains a Rabin condition. Right
now, I am using the call
autfilt --remove-dead-states --cleanup-acceptance --remove-unused-ap
--simplify-exclusive-ap --simplify-acc --partial-degeneralize
--generalized-rabin --deterministic
The last two are an effort to ensure that simplify-acc doesn't change
the acceptance condition.
2) What are the ways to tell spot to translate DRA to DPA? Right now, I
am using autfilt --hoa --deterministic --parity. This seems to be a sort
of black box (which is fine with me). Just to make sure: Are there other
DRA-to-DPA translations included in Spot which are worthwhile to be
investigated?
Cheers,
Tobias
Hi Alexandre,
I hope you are not affected too badly by COVID and you and your family can deal
with it in a good way.
Simon and I stumbled over some slight problems with ltlfilt in combination with
the flags -u and --relabel-bool=pnn. We expected to remove the duplicates, and
thus being idempotent. However, we came across a set of LTL formulas, where
two applications of ltlfilt -u --relabel-bool=pnn delivered a different result
from applying it once. I attach the set of LTL formulas (ltlfilt-duplicates/
base.ltl in the archive) and a short script to evaluate the problem (ltlfilt-
duplicates/reproduce.sh). I also tried to input a sorted list, it changed the
numbers, but not the problem of being not idempotent. Could you tell us,
whether we misunderstood something?
Best regards,
David
Tobias John <tobias.john(a)tu-dresden.de> writes:
> thanks for your quick response. Your suggestion solves my problem.
>
> I think a function like "set_default_original_states()" would be
> helpful but it is not necessary. In my opinion, it is more important
> to mention somewhere in the documentation, e.g. at
>
> https://spot.lrde.epita.fr/concepts.html#named-properties
>
> that one needs to set the property somewhen before transforming the
> automaton.
Yes. The usage is however not very uniform. Some functions, like
degeneralize() have to maintain the equivalent of "original-states" in
order to work. This function will always define "original-states" if it
wasn't present, because that comes for free. However if
"original-states" was defined previously, the two mappings will be
composed at an extra-cost.
Hello,
I am using Spot for my Master Thesis.
I try to simplify omega-automata by removing unnecessary states, e.g.
states that are unreachable. The function "purge_dead_states()" does the
job but there is an issue: for my application, I need to know the
original state numbers of the states in the resulting (smaller)
automaton, i.e. I need to map the states of the resulting automaton to
the states of the original automaton.
Is there some way to get the original state numbers from the reduced
automaton? My intuition is that the property "original-states" would be
suitable to store the original state numbers but the function
"purge_dead_states()" does not set this property.
In my opinion, the function "purge_dead_states()" setting the property
"original-states" would be a useful feature to be included in future
releases of Spot.
Best regards,
Tobias