* Tests
** operations on automata
Use ratexps as weights to check multiplication order.  As in checks for
standard(exp).

* Bugs
** is-valid(automaton)
In the case of RW, check that the ratexp is valid.

** Generators and alphabets
ladybird "works" properly on "lal_char(ab)_b", although it needs abc.
Of course, output then fails.  Should ladybird enrich the alphabet?
Or use what's in there instead of always abc?

** debug compilation mode
crange should not feature size and empty if !VCSN_DEBUG.

* Benchmarks
** determinization
Experiment determinization on (a^p)*+(a^q)*+(a^r)*, with p, q, r primes.
Possible name: "Chrobak" (reference to Marek Chrobak), "cycles", "gears".

** determinization
Introduce aaaaa+aaaab+...+bbbbb for length n.

** eps-removal
(1+a)^n

* Refactoring
** Make nullableset a labelset wrapper
One would say 'nullableset<letterset>'.  This would allow to introduce
'nullableset<tupleset<lal, lal>>', which is not possible currently.

** More documentation (AL)
The Doxygen style documentation is way too poor.  Aim at completion.

** We need to go from a labelset to its wordset
Or something like that.  I'm not sure "wordset" is appropriate, however,
polynomials for instance really need to go from label_t to word_t, and be
able to deal with them.

** scanners
The scanners are C scanners, not C++ scanners.  Therefore they don't
support streams, which is a nuisance, as our primary interface for
"conv" routines should rely on istream.

So move the scanners to Flex's C++ backend.  Then move all "conv" that
still require std::string to using std::istream, and use
misc/stream.hh:conv where we want to use strings as input.

** dyn::detail::concrete_abstract_kratexpset
Maybe it should be parameterized by a ratexpset instead of a context.

** polynomialset
It seems that monomials would be a useful abstraction.

Why "weight" in add_weight?  In place operations would be useful.

* Optimizations
** accessible etc.
The extraction of the accessible subautomaton currently requires several
traversal of the automaton, although one would suffice.  This is because it
is factored a lot, using std::copy for instance.

Keep it factored, but for instance, introduce a std::copy that walks only
the accessible parts.

** ratexpset::print
Improve the pretty-printer, there are too many parentheses.  Note that
currently we use labelset::is_letter to know if something requires
parentheses or not; this is not right.  First the name (is_letter) is
misleading and of course makes no sense for tupleset for instance, and
second, it is the wrong concept: it should really be about parentheses
(e.g., requires_parens, or whatever).

Note that the ratexp::type() are numbers that are related to precedence, so
it should be usable to determine whether parens are needed (in "a+b*"
vs. "(a+b)*" for instance).

** evaluate
Vectors of weights indexed by states are bad structures to iterate upon.  We
don't need to work on states that are not part of the computation.  This
shows in the "if (!ws_.is_zero(v1[s]))" in the code.

** power
There are better means to compute the power in some cases, see
http://en.wikipedia.org/wiki/Addition-chain_exponentiation
Also, because the algo is written recursively, we are calling
accessible too often (on products, which are accessible, of course).

** shortest, enumerate
Check that the data structures are really the best possible.  map guarantees
that if there are no deletions, references and iterator remain valid.  So we
should store references or iterators in the working queue, instead of
duplicating the monomials.

* aut-to-exp
** More heuristics
See what V1 did.

** Incremental
Transform the current implementation of the "naive" heuristics into
some incremental.  See what TAF-Kit.pdf B.1.4.1 says about it.

** Rename to a better name.
Drop "aut", because we have more entries than that.  Drop "to", as it's
clear enough from its name.

* dyn::
** Implement implicit conversions
So that, for instance, we can run is-derministic on a proper lan.

* trivial identities
As a goal, we want every rational expression to yield the same result
in lal and law.  This is a failure:

  $ vcsn-cat -C 'lal_char_z' -e 'ab{3}' -E
  (a.b){3}
  $ vcsn-cat -C 'law_char_z' -e 'ab{3}' -E
  {3}ab

Note that TAF-Kit's documentation (Section 2.2.1) precisely reports
that *both* should yield "{3}ab":

  Caveat: The definition of the identity Cat corresponds to what is
  actually implemented in Vaucanson 1.4 and is somehow a mistake. A more
  natural definition would be m{k} ⇒ {k}m with m any element of the
  monoid. This may be corrected in forthcoming revisions of Vaucanson
  1.4 but should anyway be reevaluated in connection with the definition
  of the function derived-term for the weighthed automata.

* I/O
** efsm
I/O with weights does not work.  Actually, output seems to work, but input
does not read weights.  And therefore a Z-automaton in EFSM format will be
read as a B-automaton.

Then complete efsm.chk.

** fado
I/O with words.  See the way they also _name_ states, for instance, read the
dl4.fado as generated below.

  $ vcsn ladybird -O fado 4 | \
    python -c "from FAdo import fa
  nfa = fa.readFromFile('/dev/stdin')[0]
  dfa = nfa.toDFA()
  fa.saveToFile('dl4.fado', dfa)"

** Grail
We should also be able to read Grail+ files.

** Forlan
See http://alleystoughton.us/forlan/.  In
http://alleystoughton.us/forlan/book.pdf, page 121:

  {states}
  A, B, C
  {start state}
  A
  {accepting states}
  A, C
  {transitions}
  A, 1 -> A; B, 11 -> B; C, 111 -> C;
  A, 0 -> B; A, 2 -> B;
  A, 0 -> C; A, 2 -> C;
  B, 0 -> C; B, 2 -> C

  Transitions that only differ in their right-hand states can be merged into
  single transition families. E.g., we can merge A, 0 -> B and A, 0 -> C into
  the transition family A, 0 -> B | C.

Note that "\e" is denoted "%".

** Vaucanson 1
We can easily read simple V1 automata thanks to its dot format.  However, we
must pay attention to more complex cases (e.g., rich weightsets).

However we cannot easily feed V1 with automata from V2.  This is troublesome
for benches.  However, we can probably work out something simple by using
the "edit-automaton" input of V1: we generate a script that builds the
automaton.

** XML
At some point, someone should really work on the XML formalism.

* More algorithms
** are-isomorphic
Implement it.  Sources of inspiration: Vaucanson 1 (I have been told there
are two implementations there), Forlan.

** determinization
Look for other implementations (cf. "Five determinization algorithms").  And
pay attention to the case of large alphabets.

** derived-term
Computation of the derived term automaton.

** minimization
Import what Guillaume did for Moore minimization, but without the tbb part
(for a start).  Implement more minimization algorithms (Hopcroft, Revuz,
Brzozowski...).  See how the algorithm can be adjusted to work on
non-complete automata.

** "check" algorithm
There should be a means to check that the invariants are verified.  A
separate algorithm would do.  In particular check the alphabet, that
the special letter labels the initial and final transitions etc.

** quotient
We need generalizations of minimization.  See TAF-Kit 1.

** subsequence (or subword?), prefix, suffix, factor
Generate, from an automaton, resp. a ratexp, an automaton, resp. a ratexp,
that corresponds to the subsequences, prefixes, suffixes and factors.

** Levenshtein automata
http://en.wikipedia.org/wiki/Levenshtein_automata

* edit-automaton
Currently it converts the \e in initial/final labels to the
special-letter.  Is this what we want?
Shouldn't we replace assert() with if (...) throw ... ?

* vcsn/alphabets/char.cc
  char_letters::special_letter(...) is protected and
  set_alpha<T>::add_letter(...) (in file vcsn/alphabets/setalpha.hh)
  need it.

* mutable_automaton::set_transition
We should find a means to forbid transition from pre to post.  This
was the case initially, but it is a useless constraint in aut-to-exp.
Maybe it should be efforced only in non labels_are_unit case.

* automata: handle with shared_ptr
One would really like to have a transpose_automaton that is able to
build its underlying automaton.  This means that using a const& to
keep the original automaton is not the best model: pointers would be
better.  But then there are issues with memory tracking, issues that
we already know how to handle thanks to shared_ptr.

* compilation jit
Well, you know what I mean.

* move files around
The hierarchy and the namespaces do not match.

Local Variables:
coding: utf-8
fill-column: 76
ispell-dictionary: "american"
mode: outline
End:
