jakubi

1369 Reputation

12 Badges

19 years, 332 days

MaplePrimes Activity


These are replies submitted by jakubi

I was just looking at exactly the same example of sum, and whether some strange way of functional differentiation was intended, but clearly not, this is just a bug.

I was just looking at exactly the same example of sum, and whether some strange way of functional differentiation was intended, but clearly not, this is just a bug.

Patrick, I think the OP intended sqrt in the denominator of the integrand, i.e. (...)^(1/2), not (...)^1/2.

Patrick, I think the OP intended sqrt in the denominator of the integrand, i.e. (...)^(1/2), not (...)^1/2.

This issue occurs in a simpler case as:

product(z[i], i = 1 ..n):
diff(%, z[i]);


              n   /  i - 1          \ /     n            \
            ----- | --------'       | | --------'        |
             \    |'  |  |          | |'  |  |           |
              )   |   |  |    z[i1~]| |   |  |     z[i1~]|
             /    |   |  |          | |   |  |           |
            ----- |   |  |          | |   |  |           |
            i = 1 \ i1~ = 1         / \i1~ = i + 1       /


about(i1);
Originally i1, renamed i1~:
  is assumed to be: integer

Indeed, this is a bug (either all dummy sum/product variables should be assumed integer or none)

This issue occurs in a simpler case as:

product(z[i], i = 1 ..n):
diff(%, z[i]);


              n   /  i - 1          \ /     n            \
            ----- | --------'       | | --------'        |
             \    |'  |  |          | |'  |  |           |
              )   |   |  |    z[i1~]| |   |  |     z[i1~]|
             /    |   |  |          | |   |  |           |
            ----- |   |  |          | |   |  |           |
            i = 1 \ i1~ = 1         / \i1~ = i + 1       /


about(i1);
Originally i1, renamed i1~:
  is assumed to be: integer

Indeed, this is a bug (either all dummy sum/product variables should be assumed integer or none)

Find in ?simplify/trig , the transformations this routine does. In particular, the one saying: "[...]simplify/trig factors out powers of sin(x) and cos(x) [...]". 

There are several internal routines measuring the size/complexity of the expressions, for instance simplify/size/length:

combine(eq);
`simplify/size/length`(%);
                             cos(3 theta)
                                  11

simplify(eq,trig);
`simplify/size/length`(%);

                                            2
                    cos(theta) (4 cos(theta)  - 3)
                                  33

So,it does not seem that simplify/trig performs this transformation because it considers that its output is shorter or simpler than the output of combine.

 

Find in ?simplify/trig , the transformations this routine does. In particular, the one saying: "[...]simplify/trig factors out powers of sin(x) and cos(x) [...]". 

There are several internal routines measuring the size/complexity of the expressions, for instance simplify/size/length:

combine(eq);
`simplify/size/length`(%);
                             cos(3 theta)
                                  11

simplify(eq,trig);
`simplify/size/length`(%);

                                            2
                    cos(theta) (4 cos(theta)  - 3)
                                  33

So,it does not seem that simplify/trig performs this transformation because it considers that its output is shorter or simpler than the output of combine.

 

Yes, there is a permanent tension between using the natural language style, more pleasant, but involving implicit assumptions, and the technical language, more boring but fully explicit.

It is always interesting for me observing how in some thread, missunderstandings unexpectedly arise at a point (frequently on trivialities) because diverse implicit assumptions or preconceptions on a particular issue are held by different posters.

 

Yes, there is a permanent tension between using the natural language style, more pleasant, but involving implicit assumptions, and the technical language, more boring but fully explicit.

It is always interesting for me observing how in some thread, missunderstandings unexpectedly arise at a point (frequently on trivialities) because diverse implicit assumptions or preconceptions on a particular issue are held by different posters.

 

I have written {x<>0, y finite ,x*sin(x*y)=x }.

I have written {x<>0, y finite ,x*sin(x*y)=x }.

Again in full detail: {x<>0, y finite, x*sin(x*y)=x} is equivalent to { x<>0, y finite, sin(x*y)=1}, and the latter is equivalent to { y finite, sin(x*y)=1}.

Again in full detail: {x<>0, y finite, x*sin(x*y)=x} is equivalent to { x<>0, y finite, sin(x*y)=1}, and the latter is equivalent to { y finite, sin(x*y)=1}.

As sin(x*y)=1 excludes x=0 for y finite, x*sin(x*y)=x and sin(x*y)=1 are equivalent assuming y finite.

First 8 9 10 11 12 13 14 Last Page 10 of 123