* Exercises (AP, VT)
** subword, prefix, suffix, factor
Provide the same routines for ratexps.

* Naming issues
** Wrong names
power for ratexp denotes {n,m} which is related to concat, not to mul.

** concat/mul
polynomialset uses the "concat" operator on its "labelset".  However, when
we use polynomials of ratexps, it is just "by chance" that there is a
function "concat" which is *mostly* like mul.

We should really name "concat" as "mul" in our labelsets.

** left_mult and right_mult should be lmul and rmul

** sum should be add

* Build
** -fsanitize=address
Try that on the BF.

It works well at least with clang 3.5 on OS X.  To get good error messages,
run dsymutil on all the *.dylib, something like

  find _build/35d -name '*.dylib' | xargs -n 1 dsymutil

and run the tests with $ASAN_SYMBOLIZER_PATH defined, something like

  ASAN_SYMBOLIZER_PATH=$(which llvm-symbolizer-mp-3.5) 35d check

(of course, adjust the version number, here MacPorts 3.5).

For some reason, Libtool strips this flag when linking python/vcsn-cxx.so.
To force it (which is needed), use -Wc,-fsanitize=address when linking it.

* Tests
** operations on automata
Use ratexps as weights to check multiplication order.  As in checks for
standard(exp).  We should use fewer contexts, to speed up our development.

** operations on polynomials
Check + and *.

** operations on weights
Check + and *.

** proper
Check the case where we do not want to eliminate states.  Actually check
that "a.proper(False).accessible() == a.proper()".

* Bugs
** Parse error
We need to provide more acurate locations in error messages.  For instance,
create a dot file with an incorrect context definition, and see the failure.

** shortest
Loops forever:

  $ VCSN_ORIGINS=1 vcsn standard -C 'lal_char(a)_z' -Ee 'a*+<-1>a*)' \
     | vcsn shortest -f-  1

We can check that we reach the same state, but can we have periodic
behaviors?

** infiltration does not work because of the "new_transition" optimization
The "NEWS.txt" entry is false.

  $ vcsn derived-term -C 'lal_char(ab)_b' -e 'a' -o a.gv
  $ vcsn derived-term -C 'lal_char(ab)_ratexpset<lal_char(uv)_b>' \
                      -e '(<u>a+<v>b)*' -o ab.gv
  $ vcsn infiltration -f ab.gv a.gv | vcsn shortest -f - 4
  Assertion failed: (!has_transition(src, dst, l)), function new_transition, file ../../vcsn/core/mutable-automaton.hh, line 442.
  vcsn shortest: 1.1: syntax error, unexpected $end, expecting digraph
  zsh: abort      vcsn infiltration -f ab.gv a.gv |
  zsh: exit 1     vcsn shortest -f - 4

Fix this bug, but check that we don't ruin performances of infiltration.
Uncomment the tests in infiltration.chk (there are two places).

** eliminate-states
This won't work:

  vcsn.context('ratexpset<lal_char(abc)_b>_ratexpset<lal_char(uv)_b>')

that's because we need to multiply weights of different natures, which is
something already solved in product (using conv).  See also the previous
item.

** products: lazyness
We need a lazy implementation of product.

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

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

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

** conjunction
Check star-normal-form, standard, thompson.  Check the trivial identities.
What should be the definition of the B (breaking/splitting) operator?  I
have taken a definition which is modeled after the one of concatenation (on
order "not to break too much") rather that something like expand.  What are
the expected features of the right definition?

* Cleanup
** automaton_t members in decorators
In most cases it's reasonable to use const shared_pointer (which is to say
const automaton_t) in decorators.  Check that we actually add the const
qualifier.

* 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
** Beware of our use of subprocess
I think my code is really wrong.
http://stackoverflow.com/questions/6341451/piping-together-several-subprocesses

** join and meet are messy
The current implementation has too many short coming.

- join should work with automata mixed with weights
  currently we explicitly state that the result is a mutable_automaton,
  it could be something different.

- join should code commutativity once for all

- join should code variadicity once for all

- join is spread all over the place
  There are common bits in context.hh and others in algos/product.hh.

** copy
We need a more robust copy function that can promote to a supertype.
See the hairy code and comment in

      /// Bridge.
      template <typename WeightSet, typename Aut>
      automaton
      left_mult(const weight& weight, const automaton& aut)


** Use Boost.Format to support multiple formats
We have loads of code that open-code the output format.  This is
wrong.  We should rather have format strings such as

        "%s/%s" vs. "\\frac{%s}{%s}"

and use these formats strings.  Instead of passing a format name, we would
actually pass a "format" object whose members are Boost.Formats.  It would
then be much easier to customize the pretty-printers.

Alternatively, we could also use a collection of functions/lambdas.  More
generic, and "more portable".  Note, however, that Boost.Format is
header-only.  A mixture of both might be the best: where they suffice,
format _are_ superior.

** Eliminate rat::exp
It does seem to be useful, except for one thing: dyn::ratexpset uses a
shared_ptr to exp (which is rat::exp_t is) as a means to handle ratexps.  It
would make much more sense for dyn::ratexpset to use dyn::ratexp as an
abstraction to typed ratexp, but this should be thoroughly benched to make
sure this is not (much) costlier.

Getting rid of this will allow rat::node to use single inheritance.

** Remove references to ratexp/ratexpset from context
On second thought, while it is definitely handy, it is not normal that
contexts depend on ratexpset.

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

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

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
conjunction:

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

** Dyn weights
Now that we have dynamic weights, they could be used in lib/vcsn/rat
parsing, instead of a simple string that is converted by the weightset.

** REGISTER namespace
In vcsn/ctx/instantiate.hh, we shouldn't need to say
"using namespace dyn::detail". Add it in REGISTER?

* Optimizations
** accessible etc.
The extraction of the accessible subautomaton currently requires several
traversals 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.

** constant-term
To compute the constant-term of a ratexp, we compute that of its subratexp,
which will be recomputed uselessly by derived-term.

** difference
We don't need the rhs to be complete, it suffices to adjust product to
generate a pseudo sink state each time we exit the RHS.  And of course to
change the accepting states to be the non-accepting states of the rhs.

This would avoid the completion of the rhs, which might add many many
transitions.

** 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.  On the other hand, it
is extremely efficient when the number of (concurrently) visited states is
"dense", which is the case of the bench case used in score.

So maybe we should change this bench case and rather focus on the more
common case where the number of "active" states is "sparse".

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

* change product signature to take a vector<const automaton&> instead of a
vector<automaton>

* 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
** determinization
Look for other implementations (cf. "Five determinization algorithms").  And
pay attention to the case of large alphabets.

** minimization (LS)
Implement more minimization algorithms (Hopcroft, Revuz, Brzozowski...).
Work for trim automata.

We need generalizations of minimization for weighted automata.  See TAF-Kit
1 and quotient.

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

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

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

* Readings
About dyn/static bridge:

http://www.lrde.epita.fr/dload/papers/gcse00-yrw/olena.html
ls ~theo/pub/*ouil*

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