* Build
** --enable-compilation-mode
Do not set GLIBCXX_DEBUG in speed mode.  And anyway, we have segv when both
NDEBUG and GLIBCXX_DEBUG are used.  It would be nice to find where and send
a bug report...

** Bison
It seems that Bison is needed to build from the tarball (see the MacPorts
Portfile).  We should avoid this.

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

* Bugs
** products, difference: relax the constraints on weightset
get_union and intersection on weights must be smarter, e.g., B x Z -> Z,
etc.

** difference
Once we support different weightsets, document in NEWS.

** products: lazyness
We need a lazy implementation of product.  nary product would be nice.

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

** q (LS)
We accept '1/0'.  Make sure that 0 is always 0/1.  Make sure we are
always reduced, and not overflowing.

** star-normal-form
It does not work for weighted ratexps.

** intersection
Check star-normal-form, standard, thompson.  Check the trivial identities.

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

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

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

We need to hide the map, and expose a polynomial_t type:

    /// Construction from a list of monomials.
    ///
    /// Even without this constructor we can write:
    ///
    /// polynomialset{{l1, w1}, {l2, w2}}
    ///
    /// However, it is the laws of a map that apply, not those of a
    /// polynomial.  In particular (i) if a label is zero, then the
    /// polynomial will contains such a monomial (which is forbidden),
    /// and (ii) if l1 and l2 are equal, the resulting weight will be
    /// w2 instead of w1+w2.
    polynomial(std::initializer_list<monomial_t> init)
    {
      polynomial res;
      for (const auto& m: init)
        res.add_weight(m);
      return res;
    }

likewise with assignements.  The problem came from derivation with
intersection:

      virtual void
      visit(const hadam_t& e)
      {
	e.head()->accept(*this);
	auto res = ratexp(res_);
	for (auto v: e.tail())
	  {
	    v->accept(*this);
	    res = rs_.hadam(res, ratexp(res_));
	  }
        res_ = {{res, ws_.one()}};
        apply_weights(e);
      }

here, res _can_ be \z, in which case we build a polynomial (\z -> 1), which
is forbidden (this should be the empty polynomial).

* 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 (LS)
Convert to use <= in:

      bool parent_has_precedence = precedence(child) < precedence(parent);

because we may have to deal with binary expressions (instead of variadic):
e.g. (a+b)+(c+d).  Currently we can't, agreed, but there are already
experiment where it can happen, in which case we _need_ <=, not <.

Pay attention that we want a**, not (a*)*.

** 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.  Move to "ratexp" for consistency with the name
used everywhere else.

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

** n-ary product, shuffle and infiltration
Currently it works at TAF-Kit level.  It should be easy to do at dyn::
level, and we should accept 0-ary.

It would be nice to think about n-ary static too (variadic).

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

** minimization (LS)
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 (LS)
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:
