Am Dienstag, den 02.11.2010, 13:22 -0400 schrieb Raymond Toy:
> On 11/2/10 12:41 PM, Leo Butler wrote:
> >
> > On Mon, 1 Nov 2010, Richard Fateman wrote:
> >
> > < Here is a suggestion on simplification, in terms of setting policy.
> > <
> > < Each person who makes a suggestion must fit it into a table, for
> > < simplification
> > < of x^y. (simpexpt program, or some subroutine of it will implement the
> > < policy).
> > <
> > < Across the top of the table you list the characteristics of x, and down the
> > < side
> > < you list the characteristics of y. The entry in the table says what to
> > < return.
> > <
> > < the characteristics for x include:
> > <
> > < x is an atomic symbolic literal
> > < x is an explicit positive integer
> > < x is an explicit positive rational number
> > < x is an explicit negative rational number
> > < x is zero
> > < x is a symbolic expression of the form (a^(z)) where gcd(1/z, y)= n >0, and
> > < a=polynomial.
> > < x is a symbolic expression that, after factoring, is of the form a^z ..
> > < x can be deduced by using assumptions to be positive, negative, non-negative,
> > < ....
> > <
> > < and many more.
> > <
> > <
> > < The characteristics for y include some of the same characteristics for x, but
> > < may include more
> > <
> > < There may also be a need for additional tables. For example, a whole new table
> > < for each combination
> > < of global flags that affect the simplification of x^y. If there are 3 such
> > < flags, each true/false, then there
> > < may need to be 8 tables.
> >
> >
> > RJF,
> > Your suggestion is silly, a straw man.
> >
> > You apparently are trying to ridicule the notion that one should be
> > explicit about the simplification policies one uses.
> >
> You may think it's silly, but he makes a good point. How can we decide
> on future policies if we don't even know what the policy is today? And
> how do all the flags affect the outcome?
>
> Granted x^y is particularly nasty, but consider that something simple
> like numerical evaluation of things other than x^y is messy. There are
> bug reports on how inconsistent we are with numer and float. Float
> doesn't always convert everything to a float. Numer sometimes does.
>
> If nothing else, such a table will tell us where we are.
Because of this I have started to document the behavior of the
simplification routines with the help of tables. E.g. the following
table I have already presented. This might be the desired default
simplification of the multiplication of two zeros. The current code does
not give the results of this table.
/* Table 2.1: Multiplication of zeros
*
* TIMES | 0 0.0 0.0b0 [0] [0.0] [0.0b0]
* ---------------------------------------------------------
* 0 | 0 0.0 0.0b0 [0] [0.0] [0.0b0]
* 0.0 | 0.0 0.0 0.0b0 [0.0] [0.0] [0.0b0]
* 0.0b0 | 0.0b0 0.0b0 0.0b0 [0.0b0] [0.0b0] [0.0b0]
* [0] | [0] [0.0] [0.0b0] [0] [0.0] [0.0b0]
* [0.0] | [0.0] [0.0] [0.0b0] [0.0] [0.0] [0.0b0]
* [0.0b0] | [0.0b0] [0.0b0] [0.0b0] [0.0b0] [0.0b0] [0.0b0]
*/
Dieter Kaiser