Discussion:
simplifcation of (-a)^x for a > 0
(too old to reply)
Barton Willis
2017-07-14 12:28:54 UTC
Permalink
Raw Message
Using default value for option variables and assuming a > 0, Maxima simplifies (-a)^x as a^x*(-1)^x and it simplifies (-2)^x to itself. That is arguably inconsistent--correct?


This inconsistent simplification allows some vanishing expressions to resist being simplified to zero; for example


(%i2) assume(a>0)$

(%i3) e : subst(a=2, a*(-a)^x) - 2*(-2)^x;
(e) (-1)^x*2^(x+1)+(-2)^(x+1)

(%i4) ratsimp(e);
(%o4) (-1)^x*2^(x+1)+(-2)^(x+1)

(%i5) rat(e);
(%o5)/R/ 2*(-1)^x*2^x-2*(-2)^x

(%i6) ratexpand(e);
(%o6) (-1)^x*2^(x+1)+(-2)^(x+1)

(%i7) rectform(e);
(%o7) %i*(2^(x+1)*sin(%pi*(x+1))+2^(x+1)*sin(%pi*x))+2^(x+1)*cos(%pi*(x+1))+2^(x+1)*cos(%pi*x)

(%i8) trigsimp(%);
(%o8) 0

(%i9) trigrat(e);
(%o9) 0


--Barton
Richard Fateman
2017-07-14 14:40:02 UTC
Permalink
Raw Message
It looks to me like some patchwork will be needed to make it consistent.

The way that rat() and friends tries to find "kernels" for rational
simplification
is falling short, I think.

Note however that radcan does a little better.
radcan((-4)^x); returns (-1)^x*2^(2*x)
though
radcan((-2)^x) is unchanged.

Also, if you assume(a<0) then a^x should be simplified to
(-a)^p*(-1)^p arguably.


RJF

On 7/14/2017 5:28 AM, Barton Willis wrote:
>
> Using default value for option variables and assuming a > 0, Maxima
> simplifies (-a)^x as a^x*(-1)^x and it simplifies (-2)^x to itself.
> That is arguably inconsistent--correct?
>
>
> This inconsistent simplification allows some vanishing expressions to
> resist being simplified to zero; for example
>
>
> (%i2) assume(a>0)$
>
> (%i3) e : subst(a=2, a*(-a)^x) - 2*(-2)^x;
> (e) (-1)^x*2^(x+1)+(-2)^(x+1)
>
> (%i4) ratsimp(e);
> (%o4) (-1)^x*2^(x+1)+(-2)^(x+1)
>
> (%i5) rat(e);
> (%o5)/R/ 2*(-1)^x*2^x-2*(-2)^x
>
> (%i6) ratexpand(e);
> (%o6) (-1)^x*2^(x+1)+(-2)^(x+1)
>
> (%i7) rectform(e);
> (%o7)
> %i*(2^(x+1)*sin(%pi*(x+1))+2^(x+1)*sin(%pi*x))+2^(x+1)*cos(%pi*(x+1))+2^(x+1)*cos(%pi*x)
>
> (%i8) trigsimp(%);
> (%o8) 0
>
> (%i9) trigrat(e);
> (%o9) 0
>
> --Barton
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Maxima-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Barton Willis
2017-07-14 18:13:29 UTC
Permalink
Raw Message
Another observation: for a > 0


OK:

(%i2) (-a)^q;
(%o2) a^q*(-1)^q

OK:

(%i3) (-2*(a^2+1))^q;
(%o3) (a^2+1)^q*(-1)^q*2^q

Inconsistent

(%i4) (-1*(a^2+1))^q;
(%o4) (-a^2-1)^q

But

(%i5) (-1*(a^2+1))^q,negdistrib : false;
(%o5) (a^2+1)^q*(-1)^q


The (so-called) simplification (a)^x --> (-1)^x * (-a)^x isn't governed by an easy to describe rule.




--Barton
________________________________
From: Richard Fateman <***@berkeley.edu>
Sent: Friday, July 14, 2017 9:40:02 AM
To: maxima-***@lists.sourceforge.net
Subject: Re: [Maxima-discuss] simplifcation of (-a)^x for a > 0

It looks to me like some patchwork will be needed to make it consistent.

The way that rat() and friends tries to find "kernels" for rational simplification
is falling short, I think.

Note however that radcan does a little better.
radcan((-4)^x); returns (-1)^x*2^(2*x)
though
radcan((-2)^x) is unchanged.

Also, if you assume(a<0) then a^x should be simplified to (-a)^p*(-1)^p arguably.


RJF

On 7/14/2017 5:28 AM, Barton Willis wrote:

Using default value for option variables and assuming a > 0, Maxima simplifies (-a)^x as a^x*(-1)^x and it simplifies (-2)^x to itself. That is arguably inconsistent--correct?


This inconsistent simplification allows some vanishing expressions to resist being simplified to zero; for example


(%i2) assume(a>0)$

(%i3) e : subst(a=2, a*(-a)^x) - 2*(-2)^x;
(e) (-1)^x*2^(x+1)+(-2)^(x+1)

(%i4) ratsimp(e);
(%o4) (-1)^x*2^(x+1)+(-2)^(x+1)

(%i5) rat(e);
(%o5)/R/ 2*(-1)^x*2^x-2*(-2)^x

(%i6) ratexpand(e);
(%o6) (-1)^x*2^(x+1)+(-2)^(x+1)

(%i7) rectform(e);
(%o7) %i*(2^(x+1)*sin(%pi*(x+1))+2^(x+1)*sin(%pi*x))+2^(x+1)*cos(%pi*(x+1))+2^(x+1)*cos(%pi*x)

(%i8) trigsimp(%);
(%o8) 0

(%i9) trigrat(e);
(%o9) 0


--Barton
Robert Dodier
2017-07-15 23:08:39 UTC
Permalink
Raw Message
On 2017-07-14, Barton Willis <***@unk.edu> wrote:

> Using default value for option variables and assuming a > 0, Maxima
> simplifies (-a)^x as a^x*(-1)^x and it simplifies (-2)^x to itself.
> That is arguably inconsistent--correct?

Yes, that seems inconsistent to me. It's OK by me if you want to change
it to make it more consistent.

best

Robert Dodier
Richard Fateman
2017-07-16 13:16:57 UTC
Permalink
Raw Message
On 7/15/2017 4:08 PM, Robert Dodier wrote:
>
> Yes, that seems inconsistent to me. It's OK by me if you want to change
> it to make it more consistent.
It is never entirely clear whether an existing program depends on
a particular feature. Even if the test suite runs OK with the change.
Robert Dodier
2017-07-18 05:28:43 UTC
Permalink
Raw Message
On 2017-07-16, Richard Fateman <***@berkeley.edu> wrote:

> It is never entirely clear whether an existing program depends on
> a particular feature. Even if the test suite runs OK with the change.

We are not obligated to perpetuate Maxima's many idiosyncrasies
indefinitely.

Robert Dodier
Richard Fateman
2017-07-18 05:57:55 UTC
Permalink
Raw Message
On 7/17/2017 10:28 PM, Robert Dodier wrote:
> On 2017-07-16, Richard Fateman <***@berkeley.edu> wrote:
>
>> It is never entirely clear whether an existing program depends on
>> a particular feature. Even if the test suite runs OK with the change.
> We are not obligated to perpetuate Maxima's many idiosyncrasies
> indefinitely.
>
> Robert Dodier
>
True, but one person's idiosyncrasy can be another person's
essential feature. Any transformation that requires a correct
deduction from the assume() database is relying on a feature
described in the documentation as follows:

"Maxima's deduction mechanism is not very strong; there are
many obvious consequences which cannot be determined ...."

it would be nice if someone wrote out what assume() actually
does. At least a hint.

For instance, is this a bug?

assume(x+y>3);
is (x+y>2) --> unknown

I don't know of any reference for the existing program.
Does anyone??

There are descriptions of what MIGHT be done, e.g.
see
https://www.maplesoft.com/support/help/maple/view.aspx?path=assume
especially the references there.

Would a wholesale replacement of assume() be useful?

RJF
Gunter Königsmann
2017-07-18 07:08:32 UTC
Permalink
Raw Message
It is always good to keep in mind that every change risks breaking something including code that depends on an exact ordering of the output of Maxima.

But inconsistencies like this one tend to cause wild workarounds that actively cause bugs and fixing the inconsisyency might unbreak things we don't currently test for => +1 for the change from me.

Am 18. Juli 2017 07:57:55 MESZ schrieb Richard Fateman <***@berkeley.edu>:
>On 7/17/2017 10:28 PM, Robert Dodier wrote:
>> On 2017-07-16, Richard Fateman <***@berkeley.edu> wrote:
>>
>>> It is never entirely clear whether an existing program depends on
>>> a particular feature. Even if the test suite runs OK with the
>change.
>> We are not obligated to perpetuate Maxima's many idiosyncrasies
>> indefinitely.
>>
>> Robert Dodier
>>
>True, but one person's idiosyncrasy can be another person's
>essential feature. Any transformation that requires a correct
>deduction from the assume() database is relying on a feature
>described in the documentation as follows:
>
>"Maxima's deduction mechanism is not very strong; there are
>many obvious consequences which cannot be determined ...."
>
>it would be nice if someone wrote out what assume() actually
>does. At least a hint.
>
>For instance, is this a bug?
>
>assume(x+y>3);
>is (x+y>2) --> unknown
>
>I don't know of any reference for the existing program.
>Does anyone??
>
>There are descriptions of what MIGHT be done, e.g.
>see
>https://www.maplesoft.com/support/help/maple/view.aspx?path=assume
>especially the references there.
>
>Would a wholesale replacement of assume() be useful?
>
>RJF
>
>
>
>------------------------------------------------------------------------------
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>_______________________________________________
>Maxima-discuss mailing list
>Maxima-***@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/maxima-discuss

--
Diese Nachricht wurde von meinem Android-GerÀt mit K-9 Mail gesendet.
Raymond Toy
2017-07-18 18:28:13 UTC
Permalink
Raw Message
>>>>> "Gunter" == Gunter Königsmann <***@peterpall.de> writes:

Gunter> It is always good to keep in mind that every change risks
Gunter> breaking something including code that depends on an exact
Gunter> ordering of the output of Maxima.

In this case, I would say the application is broken. While I do hate
it when the output changes (like how maxima now outputs many things
kind of sort of like (-a) + b instead of b - a), as long as the output
is still correct, I'm fine with change.

Gunter> But inconsistencies like this one tend to cause wild
Gunter> workarounds that actively cause bugs and fixing the
Gunter> inconsisyency might unbreak things we don't currently test
Gunter> for => +1 for the change from me.

Yeah, if we can fix deficiencies, we should. But Richard is also
right. One persons idiosyncracy is another's feature. And it's hard
to tell which is which.

--
Ray
Gunter Königsmann
2017-07-18 20:27:34 UTC
Permalink
Raw Message
> Yeah, if we can fix deficiencies, we should. But Richard is also
> right. One persons idiosyncracy is another's feature. And it's hard
> to tell which is which.

I have to admit that he is not only right but also formulated it in a
cool way. What I meant (but didn't manage to say, for which I have to
apologize) is: If you change a feature, unbreak 100 applications and
break one you will get exactly one bug report back. Which often causes
stronger bias against change than necessary (even if every change is
dangerous so a strong bias against change might be healthy in many places).

This time to me it seems like the change might un-break more
applications than it might break. => I would have given it a +0.5 if I
wouldn't happen to have one application that would profit from the change.

Kind regards,

Gunter.
Richard Fateman
2017-07-18 21:25:42 UTC
Permalink
Raw Message
It is perhaps worth presenting a list of what we would
like assume and "is" to do, in one place, and see how
much of it (a) works, (b) doesn't work,
(c) can be made to work,
(d) probably is too hard.

There seem to be several not necessarily conflicting,
lines of reasoning.

One is *types or categories*, using "declare" to establish
features such as integer, real, complex rational, even, odd.
(see ? features).
We can reason that an integer is necessarily real.
We have integerp(3) returns true.
declare(q,integer); integerp(q) returns false.
We can use lisp ?floatp(3.0) which returns true.

Another is "*mathematical facts*" and implications... such as

is (sin(x)^2>=0) which returns true
although sin(%i)^2 is -1.38, so the answer is incorrect.
Does assume() believe that x is real?
Setting domain:complex does not change this.
Arguably, we could have a simplification like

is (sin(x)^2>=0) simplifies to is( x an element of reals)?

Another is *deductions from **assumption data base of user f**acts*

assume(x>4);
is (x^2>16) returns true.
This kind of reasoning could be made algorithmic, for certain
kinds of assumptions. I have not looked at this recently, but
I think it is not hard to allow assumptions of linear combinations
of indeterminates like assume(3*x+4*y > 10). Such equations
determine planes or hyperplanes whose intersections can
be identified. allowing arbitrary polynomial equations is
computable at some expense via "cylindrical algebraic decomposition"
I think.

Arguably there is another source of information, the
*predicates associated with patterns*, e.g. matchdeclare(a,freeof(x)).


I invite interested parties to add to this email and send it out
again. Also, anyone interested in understanding, describing,
extending what Maxima does, should consider this as
an interesting opportunity. There is a literature on Mathematical
Knowledge Manipulation that should be, but mostly is not,
connected with computer algebra systems like Maxima.

RJF
Robert Dodier
2017-07-19 06:00:42 UTC
Permalink
Raw Message
On 2017-07-18, Raymond Toy <***@gmail.com> wrote:

> Yeah, if we can fix deficiencies, we should. But Richard is also
> right. One persons idiosyncracy is another's feature. And it's hard
> to tell which is which.

It was probably a mistake for me to use the word "idiosyncrasy." Recall
that the point of departure was that Maxima simplifies (-a)^x to
a^x*(-1)^x in the presence of assume(a > 0). It seems unlikely that
anyone actually considers that desirable, and even if they did, it's
still inconsistent with (-2)^x --> (-2)^x.

Mostly what I want to promote is the idea that we can and should fix
stuff, and we need not fear the weight of the past as we do so.

Robert Dodier
Raymond Toy
2017-07-19 15:35:49 UTC
Permalink
Raw Message
>>>>> "Robert" == Robert Dodier <***@gmail.com> writes:

Robert> On 2017-07-18, Raymond Toy <***@gmail.com> wrote:
>> Yeah, if we can fix deficiencies, we should. But Richard is also
>> right. One persons idiosyncracy is another's feature. And it's hard
>> to tell which is which.

Robert> It was probably a mistake for me to use the word "idiosyncrasy." Recall
Robert> that the point of departure was that Maxima simplifies (-a)^x to
Robert> a^x*(-1)^x in the presence of assume(a > 0). It seems unlikely that
Robert> anyone actually considers that desirable, and even if they did, it's
Robert> still inconsistent with (-2)^x --> (-2)^x.

Robert> Mostly what I want to promote is the idea that we can and should fix
Robert> stuff, and we need not fear the weight of the past as we do so.

Well, I agree and disagree. Suppose for some function foo, we simplify
it to bar. But someone wants to simplify it to the equivalent bax
which is possibly simpler in some way. Should we? Maybe yes, maybe
no. Changing it to baz will break lots of people's things and
expectations because it used to be bar. Does it make sense to do the
change? Maybe. But sometimes the answer is that we made this choice
long ago and there's nothing wrong with it so leave it.

These kinds of changes sometimes require careful thought and
discussion.

--
Ray
Richard Fateman
2017-07-19 16:54:27 UTC
Permalink
Raw Message
There certainly has been tension, over the years, between
using a small set of functions in results
with possibly complicated arguments
versus a larger set of functions with simpler arguments.
Maxima doesn't use division (too complicated?) for a/b
but uses a * (b^(-1)).

Incomplete Gamma Functions versus erf() is another example.

A more extreme example, the 1F1 Confluent Hypergeometric Functions
can be used instead of the exponential, since
Maxima knows this. Type hypergeometric([a],[a],z);

http://dlmf.nist.gov/13.1

I have no idea if using the hypergeometric() notation has advantages in, say
doing integrals. But it might.

Assuming (or hoping) the internal programs will attempt transformations
to make
the algorithms work better, we are left with considering transformations
to make the results easier for human to comprehend. Perhaps extending
the features already available via demovre and exponentialize, we could
have a general simplify(expression, favorites=[sin,cos]) versus
simplify(expression,favorites=[exp,log])
where the "favorites" list could include bessel_j, hypergeometric, ...
This kind of transformation recipe is provided in some of the competing
CAS. I don't know how effective they really are.
RJF


On 7/18/2017 11:00 PM, Robert Dodier wrote:
> On 2017-07-18, Raymond Toy <***@gmail.com> wrote:
>
>> Yeah, if we can fix deficiencies, we should. But Richard is also
>> right. One persons idiosyncracy is another's feature. And it's hard
>> to tell which is which.
> It was probably a mistake for me to use the word "idiosyncrasy." Recall
> that the point of departure was that Maxima simplifies (-a)^x to
> a^x*(-1)^x in the presence of assume(a > 0). It seems unlikely that
> anyone actually considers that desirable, and even if they did, it's
> still inconsistent with (-2)^x --> (-2)^x.
>
> Mostly what I want to promote is the idea that we can and should fix
> stuff, and we need not fear the weight of the past as we do so.
>
> Robert Dodier
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Maxima-discuss mailing list
> Maxima-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Raymond Toy
2017-07-19 20:45:48 UTC
Permalink
Raw Message
>>>>> "Richard" == Richard Fateman <***@berkeley.edu> writes:

Richard> There certainly has been tension, over the years, between
Richard> using a small set of functions in results
Richard> with possibly complicated arguments
Richard> versus a larger set of functions with simpler arguments.
Richard> Maxima doesn't use division (too complicated?) for a/b
Richard> but uses a * (b^(-1)).

Richard> Incomplete Gamma Functions versus erf() is another example.

Richard> A more extreme example, the 1F1 Confluent Hypergeometric Functions
Richard> can be used instead of the exponential, since
Richard> Maxima knows this. Type hypergeometric([a],[a],z);

Richard> http://dlmf.nist.gov/13.1

Richard> I have no idea if using the hypergeometric() notation has advantages in, say
Richard> doing integrals. But it might.

FWIW, specint does pretty much that. It converts special functions to
hypergeometric form and then tries to match that against known
integrals of hypergeometrics. This works quite well for many things.

Richard> Assuming (or hoping) the internal programs will attempt
Richard> transformations to make
Richard> the algorithms work better, we are left with considering transformations
Richard> to make the results easier for human to comprehend. Perhaps extending
Richard> the features already available via demovre and exponentialize, we could
Richard> have a general simplify(expression, favorites=[sin,cos]) versus
Richard> simplify(expression,favorites=[exp,log])
Richard> where the "favorites" list could include bessel_j, hypergeometric, ...
Richard> This kind of transformation recipe is provided in some of the competing
Richard> CAS. I don't know how effective they really are.

I think being able to convert between these things is beneficial.
Just like hgfred tries to convert hypergeometric functions to
"simpler" functions. Going the other way would be useful.

--
Ray
Loading...