|Advanced expression simplification firstname.lastname@example.org (2005-07-11)|
|Re: Advanced expression simplification email@example.com (Marco van de Voort) (2005-07-11)|
|Re: Advanced expression simplification firstname.lastname@example.org (2005-07-12)|
|Re: Advanced expression simplification email@example.com (Gene) (2005-07-17)|
|Advanced expression simplification firstname.lastname@example.org (Evangelos Drikos) (2005-07-17)|
|Re: Advanced expression simplification email@example.com (F. Liekweg) (2005-07-17)|
|From:||"F. Liekweg" <firstname.lastname@example.org>|
|Date:||17 Jul 2005 13:58:28 -0400|
|Organization:||University of Karlsruhe, Germany|
|Posted-Date:||17 Jul 2005 13:58:28 EDT|
Truly, Igor Chudov wrote on 07/11/05 13:03:
> (x^2-1)/(x-1) simplifies to x+1. GOOD
> (1^100-1)/(x-1) "simplifies" to x^99+x^98+...+x+1. NOT GOOD.
But watch out, neither case preserves the division-by-zero
condition for x==1. The code around the expression might
actually depend on this behaviour, much like the elimination
of memory stores/loads might omit null-pointer checks that
the surrounding code might depend on.
Also, if you are transforming floating-point expressions,
a seemingly more complicated expresson might be numerically
stable and more robust wrt. rounding errors that the simplified
version. In particular, inside a fixed-point iteration, a longer
expression that is better conditioned might reduce the number
of iterations needed for convergence, so that simplifying it
would be counter-productive.
Florian Liekweg | Dot is a very forgiving language; it should
Universitšt Karlsruhe | be considered some form of religion.
================================= email@example.com ==
Return to the
Search the comp.compilers archives again.