On 11/2/2010 9:41 AM, 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).
> .....
snip...
>
> (Leo:)
> 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.
Not at all. If you have simplification policies that cover all the
cases, then it is easy to
fill out the entries in the table. If you can't fill out all the
entries in the table, then you
cannot write a program to implement the policies.
It is not a straw man at all. It is something that people have already
done, in effect,
by writing the simplifier in use in Maxima. It is something that people
have already
done by writing alternative simplifiers in Maxima, which include
ratsimp, radcan,
trigsimp, poissimp, and perhaps other programs.
It is possible to write yet another simplifier, e.g. leo_dieter_simp()
that does what
you want to do, but in order to make that sensible, you have to write
out a table of
some sort, either explicitly or implicitly. This could be made rather
easily this way:
x is of the particular form prescribed by Leo_Dieter. e.g. x is
assumed > 0???
x is not of that form
y is of the particular form prescribed by Leo_Dieter. that is, y=1/2.
y is not of that form.
Then one entry in this 2X2 table is simplified according to your preference.
The other 3 entries are punted to the Maxima simplifier program.
This is different from changing the Maxima simplifier program itself.
RJF
> My point is that we'd be better off if we explicitly
> declared simplification is a matter of policy and then provided a
> convenient means to choose broad policies.
You are certainly welcome to talk about policy, but you must be able to
implement policy by programming. Ideally you would be able to demonstrate
that the implementation results are in all ways consistent. In my
experience, the best way to be consistent is to make everything correctly
reflect mathematics. CAS can do this in a way that is not generally
possible with (say) floating-point hardware, which has to deal with
overflow, underflow, roundoff, etc.
> Michel Talon's example
> of Maple's 'kamikaze' policy fits in here.
>
> I tend to think this would have the benefit of forcing users
> to be explicit about their choice of policy.
Users don't have the perspective to choose a policy. They usually try
something and go away happy or unhappy. Users may or may not
know about branch cuts or even complex numbers. Even fairly
sophisticated users may not know what to do about the behavior of
f(x,y):=x^y, where x and y are potentially complex numbers. How many
people have taken a course in the theory of SEVERAL complex
variables? Somehow a CAS needs to be able to deal with this
situation.
... snip...
>
> It seems to me that simplification cannot be consistent and therefore
> the user should have some choice where these inconsistencies arise.
Why do you say that simplification cannot be consistent?
Can you illustrate, perhaps by example, an instance of inevitable
inconsistency and also a mechanism whereby a user could
reasonably make a choice as to how to resolve this?
I am not saying that doing simplification correctly is easy. Just that
doing easy things does not make simplification correct.
RJF