I-LaSer

(Independent Language Server, v.6, web version)

Which question do you want us to solve?

Input below the approximation parameters:
Epsilon:
t (Dirichlet distribution param):
d (Displacement):

Input below the integers for the Construction question:
S (# of digits in the alphabet)
N (# of words to construct)
L (length of these words)

I-LaSer answers questions about regular languages and independent properties - prefix code property, suffix code property, ..., various error-detection and error-correction properties.

  • Satisfaction question: Given language L and property P, does L satisfy P?
  • Maximality question: Given language L and property P, is L maximal with respect to P?
  • Construction question: Given property P and integers N,k>0, return a language of N words of length k satisfying P.
  • Approximate Maximality question: Given language L, property P, and ε is the language (1-ε) close to being maximal?
Quick Notes (click on the "Technical Notes" tab for details): Languages are provided by automata; properties are either fixed, or provided by transducers or trajectory expressions. The alphabets of the given property and the language involved must be the same. The computation of the Construction question produces languages over an alphabet of the form {0,1,...,s} with 2 ≤ s ≤ 10. For online-computation (via "Submit Request") the sizes of the automata and transducers involved are limited.

SOME TECHNICAL NOTES

What is this about? This server allows a user to specify one of 4 questions about properties of regular languages and provides an answer to the specified question.
  • The Satisfaction question: The user enters the description of a regular language via a finite automaton or a regular expression, and the description of a language property, and returns YES/NO, depending on whether the language satisfies the property. If the answer is NO, appropriate counterexamples (also called witness words) are provided.
  • The Maximality question: If a language satisfies a property, the user can ask the server to decide whether the language is maximal with respect to the property. Being maximal means that if any new words are added to the language the resulting language would violate the property. If the language is not maximal then the server returns a word that can be added to the language. The Maximality question is PSPACE-hard, which means that for certain inputs the server would need a very long time to produce the answer.
  • The Construction question: The user enters the description of a property and three positive integers s, N, k, and generates a language of (up to) N words of length k satisfying the given property [KoMoRe]. The integer s must be less than 10 and specifies that the alphabet must be {'0','1',...,'s'}.
  • The Approximate Maximality question: As the Maximality question is hard, the server also provides an answer to the Approximate Maximality question based on the PRAX algorithms in [KoMaMoRe]. The main idea behind Approximate Maximality of a language (with respect to a property) is as follows: if a sample of words is generated, and if every generated word violates the property when it is added to the given language then the language is probably close to being maximal. The user enters a regular language and a property as above, and an approximation tolerance ε, with 0<ε<1, and the server returns, either that the language is not maximal (providing also a word that can be added), or that the language is probably (1-ε) close to being maximal. The size of the sample of words depends on ε (smaller ε implies larger size). Each word is sampled in 2 steps: first the length is selected according to the Dirichlet distribution D(t), [Gol,KoMaMoRe], and then the letters of the word according to the unifirm distribution on the alphabet. The parameter t must be > 1; however, the closer t is to 1 the longer the sampled words can be, and the algorithm would be slower. When t=2 the sampled words are not very long but the selected length would be biased.
See further below how to describe properties.

Online computation vs Program generation: When a user specifies a question to solve and the required input, I-LaSer either computes the answer in real time, if the user clicks on "Submit Request", or it produces a zip file containing a self contained Python3 executable file, if the user clicks on "Generate Program". In the latter case, the executable file can produce the answer on the user's local machine.
Limits on online computations: Depending on the sizes of the given automaton and transducer, the underlying software could perform a great deal of processing before it returns an answer. For this reason, the following limits on processing requests are enforced.
  • No execution can take longer than 15 sec. (Use the Program Generation option, or any locally-run version of I-LASer which can be downloaded from the links below, for longer executions.)
  • Requests for the Satisfaction question are not processed, if the quantity N*N*M exceeds 500,000, where N and M are the numbers of transitions in the automaton and transducer, respectively.
  • Requests for the Construction question are not processed, if the quantity N*N*L*M exceeds 500,000, where N is the requested number of words, L is the requested length of these words, and M is, either the number of transitions in the transducer describing the property, or M=1 if the property is fixed.

Properties. Examples of language properties are: prefix code, infix code, 1-substitution-error-detecting language [ShyThi,Shyr,JuKon]. These are examples of independences (independent properties). Roughly speaking, a language satisfies an independence if every subset of the language also satisfies that independence. Many independent properties have the following characteristic: a language L satisfies the property P if there are NO different words u,v in L such that v can result by performing a certain word operation on u--this word operation is what defines the property P. For example, prefix codes are defined by the word operation of removing any nonempty ending of the word u; and 1-substitution-detecting languages are defined by the operation that changes exactly 1 symbol in the word u. Transducers can conveniently be used to realize many such operations, and we say that each such transducer describes a property. The method of trajectories is more limited in describing independences, but the descriptions are much simpler. I-LaSer supports the following independent properties.

  • Fixed properties: These are UD code (uniquely decipherable/decodable code), prefix code, suffix code, bifix code, infix code, outfix code, hypercode.
  • Regular trajectory properties [Dom]: A regular expression e over {0, 1} describes the following property. All languages L in which no two words are related as expressed in e. In particular, when the zeros in e represent positions of a word v in L, then there can be no other word in L containg v as expressed in e. For example, 0*1* describes the prefix code property, since a prefix code cannot have a word u containing another word v as a prefix (v as 0* and u as 0*1*). Similarly, 1*0* describes the suffix code property.
  • Input-altering Transducer properties [DuKon]: A transducer t is a nondeterministic automaton with output such that t(w) = the set of possible output words of t when the input is the word w. Note that t(w) could be empty for some words w. An input-altering transducer is one such that, for any input word w, the output is never equal to w. An input-altering transducer t describes the following property. All languages L such that t(L) ∩ L = EmptySet, that is, the transducer t cannot take as input an L-word and also output an L-word. For example, the prefix code property can be described via a transducer that, on input w, returns all proper prefixes of w---see Format for transducers for more details.
  • Input-preserving Transducer properties (also called Error-detecting properties) [DuKon,KoMeMoRe]: Such a property is described by an input-preserving transducer t as follows. All languages L such that y in t(x) implies y=x, for any words x, y in L; that is, on any input word x from L, the transducer t will never output another word in L. An input-preserving transducer, also called channel, is a transducer t that, on any input word w for which t(w) is nonempty, the set t(w) includes w; thus, t acts as a communication channel that receives a word w and can always return w (case of no error) or posiibly a word other than w (case of error). For example, the 1-subsitution-detection property can be described by a transducer that, on input w, returns either w or any word that obtains by changing 1 symbol of w---see Format for transducers for examples.
  • Error-correcting properties [KoMeMoRe]: Such a property is described by an input-preserving transducer t as follows. All languages L such that w in t(x) and w in t(y) implies y=x, for any words x, y in L and any word w; that is, the transducer cannot turn two different input words x, y from L into the same word. For example, the 1-subsitution-correction property can be described by a transducer that, on input w, returns either w or any word that obtains by changing 1 symbol of w.
  • DNA-type transducer properties [KaKoKo]: Such a property is described by a transducer t and an antimorphic involution θ as follows. All languages L such that t(L) ∩ θ(L) = EmptySet, that is, the transducer cannot turn a word in L to a word in θ(L).

Implementation: Based on FAdo, a package of Python libraries, which includes modules for automata, transducers, and code properties.

Some References

[AAAMR] Andre Almeida, Marco Almeida, Jose Alves, Nelma Moreira, and Rogério Reis (2009): FAdo and Guitar: tools for automata manipulation and visualization. In S. Maneth, editor, CIAA 2009: Fourteenth International Conference on Implementation and Application of Automata, volume 5642 of Lecture Notes on Computer Science, pages 65-74, Sydney, Australia, July 2009. Springer-Verlag.
[Dass] Jürgen Dassow. Comment following the presentation in [DuKon].
[Dom] M. Domaratzki (2004): Trajectory-Based Codes. Acta Informatica, vol. 40, n. 6-7 (2004) 491-527.
[DuKon] K. Dudzinski and S. Konstantinidis (2010): Formal descriptions of code properties: decidability, complexity, implementation. International Journal of Foundations of Computer Science 23:1 (2012), 67--85. Presented at DCFS 2010.
[FAdo] FAdo: Tools for Formal Languages manipulation.
[Gol] Solomon W. Golomb (1970): A class of probability distributions on the integers. Journal of Number Theory 2 (1970) 189–192.
[JuKon] H. Jürgensen and S. Konstantinidis (1997): Codes. In G. Rozenberg, A. Salomaa (eds): Handbook of Formal Languages, vol. I, 511-607. Springer-Verlag, Berlin, 1997.
[KaKoKo] Lila Kari, Stavros Konstantinidis, Steffen Kopecki (2018). Transducer descriptions of DNA code properties and undecidability of antimorphic problems. Inform. Comput. 259(2): 237-258 (2018). Also presented in: DCFS 2015, University of Waterloo, Canada.
[KoMaMoRe] Stavros Konstantinidis, Mitja Mastnak, Nelma Moreira, Rogério Reis (2022, 2023): Approximate NFA universality and related problems motivated by information theory. Theor. Comput. Sci. (2023). Also: Approximate NFA universality motivated by information theory. LNCS 13439: DCFS 2022 142-154, Debrecen, Hungary, August 29-31, 2022.
[KoMeMoRe] Stavros Konstantinidis, Casey Meijer, Nelma Moreira, Rogério Reis (2016,2018): Symbolic Manipulation of Code Properties”. J. Autom. Lang. Comb. 23 (2018). Also: Implementation of Code Properties via Transducers. Lecture Notes in Computer Science 9705, 21st International Conference on the Implementation and Application of Automata (CIAA 2016), Seoul, Korea, Republic of (189-201). Also: Symbolic manipulation of code properties. arXiv:1504.04715v1, 2015.
[KoMoRe] Stavros Konstantinidis, Nelma Moreira, Rogério Reis (2016, 2018): Randomized generation of error control codes with automata and transducers. RAIRO Theor. Informatics Appl. 52(2-3-4): 169-184 (2018). Also: Generating Error Control Codes with Automata and Transducers. 8th Workshop on Non-Classical Models of Automata and Applications, Debrecen, Hungary, OCG Proceedings.
[Shyr] H.J. Shyr. Free monoids and languages. Hon Min Book Company, Taichung, Taiwan, 1991.
[ShyThi] H.J. Shyr and G. Thierrin. Codes and binary relations. Seminaire d'Algebre Paul Dubreil, Paris 1975--1976 (29\`eme Ann\'ee), Lecture Notes in Mathematics, 586, 1977, 180--188.

ABOUT I-LaSer

(Names of I-LaSer versions are those of research students who contributed to their implementation)

Project initiator: Stavros Konstantinidis (http://cs.smu.ca/~stavros/)

Significant contributors:

Nelma Moreira & Rogerio Reis: as of version 3, LaSer's back end is based on FAdo

6: Baxter Madore (August 2024, current version)
Incorporating the approximate maximality question, and adding time limits to computations.

5: Matthew Rafuse (January 2018)
Incorporating into LaSer satisfaction of DNA properties, introducing text areas for entering user input, and making the views.py code modular.

4: Abisola Adeniran (October 2016)
Incorporating into LaSer the construction problem.

3: Casey Meijer (June 2014)
Deciding maximality of all available properties, generation of executable code

2: Meng Yang (June 2012)
Deciding satisfaction of: Input-preserving transducer, Error-detection, and Error-correction properties

1: Krystian Dudzinski (June 2010)
Deciding satisfaction of: Trajectory and Input-altering transducer properties

Format for Automata

One can use the Grail and FAdo formats for nondeterministic finite automata (those with nonempty transitions). The format of FAdo files must be as follows:

  1. '#' begins a comment
  2. @NFA, or @DFA, begins a new automaton (and determines its type) and must be followed by the list of the final states separated by blanks
  3. Transitions are written one per line and consist of three fields separated by blanks: "state" "symbol" "new state"
  4. The source state of the first transition is the initial state, or initial states can be specified by listing them after the end states and an asterisk.

Here is an example of an automaton accepting ab* using both, Grail and FAdo formats:

Grail:   
(START) |- 1
1 a 2
2 b 2
2 -| (FINAL)
        
FAdo:   
@NFA 2
1 a 2
2 b 2
        

More examples follow:

Automaton accepting aaa(aaa)*b + aa(ba)*a(aa(ba)*a)*b:

Grail:   
(START) |- 1
1 a 2
2 a 3
3 b 2
3 a 4
4 a 2
4 b 8
1 a 5
5 a 6
6 a 7
7 a 5
7 b 8
8 -| (FINAL)
        
FAdo: 
@NFA 8
1 a 2
2 a 3
3 b 2
3 a 4
4 a 2
4 b 8
1 a 5
5 a 6
6 a 7
7 a 5
7 b 8
        

Automaton accepting ab + bba:

Grail:         
(START) |- 1
1 a 2
2 b 3
1 b 4
4 b 5
5 a 3
3 -| (FINAL)
        
FAdo:  
@NFA 3
1 a 2
2 b 3
1 b 4
4 b 5
5 a 3
        

Format for Transducers

As of June 2014, only the FAdo format of transducers is accepted, as the Grail-like format is not generally supported. Transducers must be in standard form, that is, having transitions of the form   p x y q, where p and q are states, and each of x and y is either a single alphabet symbol or the empty word. The empty word is written as @epsilon. The format of transducer FAdo files must be as follows:

  1. '#' begins a comment
  2. @Transducer begins a new transducer and must be followed by the list of the final states separated
  3. by blanks
  4. Transitions are written one per line and must be in standard form as noted above.
  5. The source state of the first transition is the initial state.

Please see the FAdo documentation for the full description of Transducer format.

Below is an example of an input-altering transducer describing the suffix code property over the alphabet {a, b}. The transducer outputs any proper suffix of a given input word.


@Transducer 2 3
1 a @epsilon 2
1 b @epsilon 2
2 a @epsilon 2
2 b @epsilon 2
2 a a 3
2 b b 3
3 a a 3
3 b b 3
        

More examples below:

Input-preserving transducer describing the 1-substitution-detecting property over the alphabet {0, 1}. On input w, the transducer outputs either w, or any word resulting by substituting 1 bit of w with a different bit.


@Transducer 0 1
0 0 0 0
0 1 1 0
0 0 1 1
0 1 0 1
1 0 0 1
1 1 1 1
        

Input-preserving transducer describing the 1-sid-detecting property over the alphabet {a, b}. On input w, the transducer outputs any word resulting by performing at most one symbol substitution/insertion/deletion operation on w.


@Transducer 0 1
0 a a 0
0 b b 0
0 a b 1
0 b a 1
0 a @epsilon 1
0 b @epsilon 1
0 @epsilon a 1
0 @epsilon b 1
1 a a 1
1 b b 1
        

Input-altering transducer describing the thin property (= all languages whose words are of different lengths). On input w, the transducer outputs any word of the same length as w, but different from w.


@Transducer 2
1 a a 1
1 b b 1
1 a b 2
1 b a 2
2 a a 2
2 b b 2
2 a b 2
2 b a 2
        

Format for Trajectory Expressions

Regular trajectory properties can be described via regular expressions over {0,1} in the FAdo format. For example:

-- the regular expression 1*0* describes the suffix code property;
-- the regular expression 1*0*1* describes the infix code property;
-- the regular expression 0*1* + 1*0* describes the bifix code property (being prefix and suffix code).

Format for Antimorphisms

Theta Antimorphisms are used to answer questions about certain DNA properties.

Below is an example of an antimorphism describing the DNA antimorphism over the DNA alphabet: θ(a)=t, θ(t)=a , θ(g)=c, θ(c)=g. There is no need to add the inverses, as LaSer does this automatically.


@Theta
a t
g c