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.
Now if someone says, here's an example that I would like to come out in
a particular way, it is
important to check all the entries in related rows and columns to see if
that leads to an inconsistency.
Here is the kind of inconsistency that tends to come up.
Simplifying f(x,y) results in g(x,y), symbolically.
but substituting particular numeric values for x, and y, say x0 and
y0, gives DIFFERENT values for f(x0,y0) and g(x0,y0).
Here is another:
While f(x,y) appears to be an analytic function, g(x,y) is not
continuous, or not differentiable.
Deciding that sqrt(4) must be 2 seems harmless, but what policy does
that imply, for consistency,
for (4)^(1/4)? Note, incidentally, that some writers consider
sqrt(x) and x^(1/2) to have different
meanings.
RJF
On 11/1/2010 10:56 AM, Dieter Kaiser wrote:
> Am Montag, den 01.11.2010, 08:15 +0000 schrieb Leo Butler:
>> <snip>
>>
>> I'd like to suggest an alternative, which I do so in the blissful
>> ignorance of the simplifier. I'd like to suggest that instead of
>> butting heads over which is the right way to do simplification, we
>> improve the configurability and/or modularity of the simplifier,
>> so that the user can choose the right simplification policy.
>>
>> What I have in mind includes:
>>
>> 1. assemble several 'standard' or useful configurations of the
>> simplifier and create a single function that lets the user
>> select configurations, or create new ones.
>>
>> 2. add health warnings in the documentation to clarify what is
>> meant by simplification.
>>
>> I tend to think that simplification is more a question of implementing
>> a *policy* as opposed to getting a mathematically correct answer.
>> What I mean is that most users, most of the time, want Maxima's
>> simplifier to do what they would do (e.g. sqrt(4) -> 2), and they
>> tend to get upset when this doesn't happen -- even when they know
>> better and know it is 'wrong'. So we should have a simplifier policy
>> ('high_school_algebra') that implements this. But it would be
>> wrong to commit the Maxima simplifier to this policy in the large.
>>
>> Leo
> Yes, that is my opinion, too. I agree with your suggestions. I think it
> is not to difficult to get a consistent implementation of some
> simplification policies. It is more difficult to define these policies.
>
> Dieter Kaiser
>
>