#51 trigsimp produces "Simplification recursion too deep" on attempting 1-sin^2

[Alastair Rucklidge]

I came across this curious problem today: trigsimp gives "Simplification recursion too deep" errors trying to simplify 1-sin^2(x), for some choices of x.

CSL was coded by Codemist Ltd, 1988-2008
Distributed under the Modified BSD License
REDUCE, 15-Sep-08 ...

1: 1-(sin(pix/2))*2;

    pi*x  2

• sin(------) + 1
  2

2: trigsimp(ws);

* sub

3: trigsimp(ws,cos);

* Simplification recursion too deep

* Invalid simplification

Oh dear. A similar exercise with x instead of pi*x/2 was OK:

CSL was coded by Codemist Ltd, 1988-2008
Distributed under the Modified BSD License
REDUCE, 15-Sep-08 ...

1: 1-(sin(x))**2;

     2

• sin(x) + 1

2: trigsimp(ws);

     2

• sin(x) + 1

3: trigsimp(ws,cos);

  2

cos(x)

I've tried a few other choices for x in the above (e.g., xy, x/y, pix) and they are all OK -- it is only pi*x/2 that I've found that gives this problem.

Many thanks for any help!

Alastair Rucklidge

[Alastair Rucklidge]

Apologies for the formatting in the post: all my minus signs and stars have turned in to bullet points. How about:

1: off nat;

2: 1-(sin(pi*x/2))**2;

- sin((pi*x)/2)**2 + 1$

3: trigsimp(ws);

***** sub

4: trigsimp(ws,cos);

***** Simplification recursion too deep

***** Invalid simplification

[Arthur Norman]

I came across this curious problem today: trigsimp gives
"Simplification recursion too deep" errors trying to simplify 1-sin^2(x),
for some choices of x.

CSL was coded by Codemist Ltd, 1988-2008
Distributed under the Modified BSD License
REDUCE, 15-Sep-08 ...

1: 1-(sin(pix/2))*2;

   pi*x  2

• sin(------) + 1
  2

2: trigsimp(ws);

* sub

The copy of Reduce you are using seems maybe a little old - when we
produce a fix to this problem the way you will get access to it fastest
will be if you find out how to fetch the latest sources using subversion
and build everything locally for yourself. However I checked your exammple
and it fails in the current version too!

Indeed merely
trigsimp sin(xy/2);
seems to crash things, and this seems to be in subs_symbolic_multiples
where I believe at present the code is trying to do a substutution
xy => 2*aux_symbolic_var(1)
and choking on being passed a product not a single kernel to substitute
for.

The code is in packages/trigsimp/simptrg2.red.

I will look some more later on...
Arthur

[Rainer Schöpf]

There are two separate issues here: the first one is the error pointed out by Arthur. In addition, Reduce fails to print a sensible error message. I have already identified the cause for this and will checkin an attempt to correct it later today.

Rainer

[Rainer Schöpf]

Addendum: the error can be triggered by the input

sub(x*y=1,z);

so it's not a trigsimp problem per se.

-Rainer

[Rainer Schöpf]

The cause of the problem is indeed the code in the trigsimp package that tries to substitute a product by a kernel, This is not possible with the sub operator, only with a local rule (i.e. a WHERE clause).

I will commit the correction after proper testing.

Rainer

[Arthur Norman]

On Fri, 28 Jun 2013, "Rainer Schöpf" wrote:

There are two separate issues here: the first one is the error pointed out
by Arthur. In addition, Reduce fails to print a sensible error message. I
have already identified the cause for this and will checkin an attempt to
correct it later today.

Rainer

Excellent. I note that the cases I see as bad are trigsimp on:
sin(1/2) tries 1 => 2temp to clear the fraction
sin(xy/2) tries xy => 2temp and you might hope that the
substitution would survive. I could imagine using
merely x => 2temp OR y => 2temp but see below!
sin(x^2/2) tries x^2 => 2temp ditto
sin(1/(2x)) 1/x => 2temp
sin(1/(2x)) + sin(x/2) might want to make x = 2temp1 and 1/(2temp2))
to clear both fractions!
sin(x/(2y)) + sin(y/(3x)) similarly the strategy of substituting for x
and y to clear fractions will not work very well!

So what I can see how to fix quickly and easily is just only to try the
substututions in cases where they at least stand a chance of not causing
the substitution machinery to fail but in the light of the last two cases
above I am at present uncertain about a global proper fix. In particular a
mere fix that lets xy => 2temp will improve things but not (I believe)
fix everything.

     Arthur

[Rainer Schöpf]

Correction committed.