On Wed, Oct 5, 2011 at 3:17 PM, Goswin von Brederlow <goswin-...@web.de> wrote: > (1*Y)? That certainly isn't optimal.
The inefficiency is in the code translating the semantic value back into the expression type, not in the evaluation code. Feel free to add the few lines needed to spot that corner case and behave accordingly, as I did for the initialization of the sum (to avoid "+ 0" everywhere). Note that this doesn't stop the simplification to be involutive, so still a valid simplification/normalization; whether the normal form actually respects our sense of "optimality" is a different question. On Wed, Oct 5, 2011 at 3:17 PM, Goswin von Brederlow <goswin-...@web.de> wrote: > Gabriel Scherer <gabriel.sche...@gmail.com> writes: > >>> Below is a quick tentative implementation of NbE, on a slightly >>> restricted expression type (I removed the not-so-interesting Minus >>> nodes). >> >> Sorry, I forgot to give a small example of what the implementation >> does. Really the obvious thing, but it may not be so obvious just >> looking at the code. >> Here is an example of (X*2+Y)*(3+(Y*2+Z)) being 'rewritten' to >> (1*Y)*Z+((2*Y)*Y+(3*Y+((2*X)*Z+((4*X)*Y+6*X)))). > > (1*Y)? That certainly isn't optimal. > > MfG > Goswin > -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
