Good point, about inner assumptions not being inferred from the outer ranges.

But I still wonder why the example worked in version9.03 (and earlier) and then broke in version 9.5 (and later).

It's possible that it used to work "by accident", due to some bug that since got fixed. It does (rarely) happen that functionality relies on a chain of fortuitous bugs, such that a fix to one of the bugs breaks an apparently good example. But I don't know if that's the case here.

acer

Good point, about inner assumptions not being inferred from the outer ranges.

But I still wonder why the example worked in version9.03 (and earlier) and then broke in version 9.5 (and later).

It's possible that it used to work "by accident", due to some bug that since got fixed. It does (rarely) happen that functionality relies on a chain of fortuitous bugs, such that a fix to one of the bugs breaks an apparently good example. But I don't know if that's the case here.

acer

> printf("name\t%d\t%d\t=\t%g\n", 13,17,19.3457);
name    13      17      =       19.3457

See Maple's backslash help-page.

acer

> printf("name\t%d\t%d\t=\t%g\n", 13,17,19.3457);
name    13      17      =       19.3457

See Maple's backslash help-page.

acer

The ?sum help-page mentions that add is capable of such finite addition. And, indeed, it is usually preferred.

But the question may still be asked, why doesn't it work as follows for sum,

> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                    (2 - m)
                                   2
                                  -----------
                                  (2 - m)! m!

> sum(%,m=0..2);
                                      9/2

Also, note that you invoked limit(%%,N=2-m), but the previous line produced an error. So it looks as if limit was being applied to 0 the penultimate result and not to the expression containing hypergeom. Hence it is not clear why this produces 0 in Maple 12.02,

> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                       0

Indeed,

maple9.03> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                      4
                                --------------
                                             m
                                (2 - m)! m! 2

maple9.03> sum(%,m=0..2);
                                      9/2

while,

maple9.50> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);

                                       0

acer

The ?sum help-page mentions that add is capable of such finite addition. And, indeed, it is usually preferred.

But the question may still be asked, why doesn't it work as follows for sum,

> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                    (2 - m)
                                   2
                                  -----------
                                  (2 - m)! m!

> sum(%,m=0..2);
                                      9/2

Also, note that you invoked limit(%%,N=2-m), but the previous line produced an error. So it looks as if limit was being applied to 0 the penultimate result and not to the expression containing hypergeom. Hence it is not clear why this produces 0 in Maple 12.02,

> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                       0

Indeed,

maple9.03> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);
                                      4
                                --------------
                                             m
                                (2 - m)! m! 2

maple9.03> sum(%,m=0..2);
                                      9/2

while,

maple9.50> sum(sum(1/k!/j!/m!,k=2-m-j..2-m-j),j=0..2-m);

                                       0

acer

The apparent "powers" in the derivatives' output are simply artefacts of the notation -- it's just how they get printed but not how they are represented in the underlying structure.

You can use eval in the usual way, to evaluate after substitution,

> expr := sin(x)*diff(f(x),x,x)/sqrt(diff(f(x),x));
                                          / 2      \
                                          |d       |
                                   sin(x) |--- f(x)|
                                          |  2     |
                                          \dx      /
                           expr := -----------------
                                     /d      \1/2
                                     |-- f(x)|
                                     \dx     /

> lprint(expr);
sin(x)*diff(diff(f(x),x),x)/diff(f(x),x)^(1/2)
 
> eval(expr, [diff(f(x),x)=4.0, diff(f(x),x,x)=-17.0]);
                              -8.500000000 sin(x)

acer

Yes, similarity is necessary, and so I tried be phrase it carefully. You had asked about efficient means, and since the problem is hard it seemed to me that a test of some necessary conditions (at a cost like that of, say, eigenvalue computation) might be of some use in practice. It might be used as a (reasonably low complexity) rejection filter.

acer

Yes, similarity is necessary, and so I tried be phrase it carefully. You had asked about efficient means, and since the problem is hard it seemed to me that a test of some necessary conditions (at a cost like that of, say, eigenvalue computation) might be of some use in practice. It might be used as a (reasonably low complexity) rejection filter.

acer

If Matrices A and B are not similar then there is no invertible Matrix C such that C.A=B.C, and hence no P=C^(-1) with the same property. See IsSimilar. For floating-point Matrices, you might consider looking at eigenvalues.

acer

If Matrices A and B are not similar then there is no invertible Matrix C such that C.A=B.C, and hence no P=C^(-1) with the same property. See IsSimilar. For floating-point Matrices, you might consider looking at eigenvalues.

acer

> M := Matrix(2,2,symbol=m);
                                [m[1, 1]    m[1, 2]]
                           M := [                  ]
                                [m[2, 1]    m[2, 2]]
 
> M^(-1) ;
                           [ m[2, 2]       m[1, 2]]
                           [ -------     - -------]
                           [   %1            %1   ]
                           [                      ]
                           [  m[2, 1]     m[1, 1] ]
                           [- -------     ------- ]
                           [    %1          %1    ]
 
                    %1 := m[1, 1] m[2, 2] - m[1, 2] m[2, 1]

There are the formulae for each entry of the inverse of a general 2x2 Matrix. Just code those up in a procedure that accepts argument m (a 2x2 Matrix).

acer

> M := Matrix(2,2,symbol=m);
                                [m[1, 1]    m[1, 2]]
                           M := [                  ]
                                [m[2, 1]    m[2, 2]]
 
> M^(-1) ;
                           [ m[2, 2]       m[1, 2]]
                           [ -------     - -------]
                           [   %1            %1   ]
                           [                      ]
                           [  m[2, 1]     m[1, 1] ]
                           [- -------     ------- ]
                           [    %1          %1    ]
 
                    %1 := m[1, 1] m[2, 2] - m[1, 2] m[2, 1]

There are the formulae for each entry of the inverse of a general 2x2 Matrix. Just code those up in a procedure that accepts argument m (a 2x2 Matrix).

acer

The user can create a initialization file to correct a bad default value for currentdir. The user can also adjust the Properties of the desktop launcher to correct a bad default value for currentdir.

The user can fix the bad default currentdir value, if told how. That is not at issue.

My point is that users (and especially new users) will have little or no idea how to do these things, or even be aware that they could/should be done. It should be fixed in the product.

acer

The user can create a initialization file to correct a bad default value for currentdir. The user can also adjust the Properties of the desktop launcher to correct a bad default value for currentdir.

The user can fix the bad default currentdir value, if told how. That is not at issue.

My point is that users (and especially new users) will have little or no idea how to do these things, or even be aware that they could/should be done. It should be fixed in the product.

acer