@Preben Alsholm 

Interesting, so there are several concurrent problems. First, coeff admits a series object as input, which is undocumented. Then the bug in series that you show. And finally, the procedure residue should be able to use either series methods, series or MultiSeries:-series (the same as definite integration, for a check when one or the other is wrong). So, in the mean time, a workaround is:

> unprotect(series):
> series:=MultiSeries:-series:
> residue(1/(2^s-1), s=2*Pi*I*3/log(2));
                                       1
                                ---------------
                                       /6 I Pi\
                                       |------|
                                       \ln(2) /
                                ln(2) 2
> simplify(%);
                                       1
                                     -----
                                     ln(2)

@Carl Love 

See e.g this collection of 1D vs 2D parser differences.

@Carl Love 

See e.g this collection of 1D vs 2D parser differences.

It seems like the cause of this issue is programmer indexing, independently of any resizing or chopping:

> M:=Array(1..2,1..2,(i,j)->exp(i*x+j*y));
                          [ exp(x + y)      exp(x + 2 y) ]
                     M := [                              ]
                          [exp(2 x + y)    exp(2 x + 2 y)]

> subs(x=.1,y=.3,M);
                          [1.491824698    2.013752707]
                          [                          ]
                          [1.648721271    2.225540928]

> lprint(%);
Array(1 .. 2,1 .. 2,{(1, 1) = exp(.4), (1, 2) = exp(.7), (2, 1) = exp(.5), (2,
2) = exp(.8)},datatype = anything,storage = rectangular,order = Fortran_order)

> M:=M(..,..);
                          [ exp(x + y)      exp(x + 2 y) ]
                     M := [                              ]
                          [exp(2 x + y)    exp(2 x + 2 y)]

> Ml:=M(..);
         Ml := [exp(x + y), exp(2 x + y), exp(x + 2 y), exp(2 x + 2 y)]

> subs(x=.1,y=.3,M);
                        [ exp(x + y)      exp(x + 2 y) ]
                        [                              ]
                        [exp(2 x + y)    exp(2 x + 2 y)]

> subs(x=.1,y=.3,Ml);
            [exp(x + y), exp(2 x + y), exp(x + 2 y), exp(2 x + 2 y)]

> map2(subs,[x=.1,y=.3],M);
                             [exp(0.4)    exp(0.7)]
                             [                    ]
                             [exp(0.5)    exp(0.8)]

> map2(subs,[x=.1,y=.3],Ml);
                    [exp(0.4), exp(0.5), exp(0.7), exp(0.8)]

It is not clear to me whether the cause of this behavior is an interfering flag, or that the "newer view" that programmer indexing provides of the object is not what subs or eval expects to receive. To my taste, ?rtable_indexing is somewhat obscure.

It seems like the cause of this issue is programmer indexing, independently of any resizing or chopping:

> M:=Array(1..2,1..2,(i,j)->exp(i*x+j*y));
                          [ exp(x + y)      exp(x + 2 y) ]
                     M := [                              ]
                          [exp(2 x + y)    exp(2 x + 2 y)]

> subs(x=.1,y=.3,M);
                          [1.491824698    2.013752707]
                          [                          ]
                          [1.648721271    2.225540928]

> lprint(%);
Array(1 .. 2,1 .. 2,{(1, 1) = exp(.4), (1, 2) = exp(.7), (2, 1) = exp(.5), (2,
2) = exp(.8)},datatype = anything,storage = rectangular,order = Fortran_order)

> M:=M(..,..);
                          [ exp(x + y)      exp(x + 2 y) ]
                     M := [                              ]
                          [exp(2 x + y)    exp(2 x + 2 y)]

> Ml:=M(..);
         Ml := [exp(x + y), exp(2 x + y), exp(x + 2 y), exp(2 x + 2 y)]

> subs(x=.1,y=.3,M);
                        [ exp(x + y)      exp(x + 2 y) ]
                        [                              ]
                        [exp(2 x + y)    exp(2 x + 2 y)]

> subs(x=.1,y=.3,Ml);
            [exp(x + y), exp(2 x + y), exp(x + 2 y), exp(2 x + 2 y)]

> map2(subs,[x=.1,y=.3],M);
                             [exp(0.4)    exp(0.7)]
                             [                    ]
                             [exp(0.5)    exp(0.8)]

> map2(subs,[x=.1,y=.3],Ml);
                    [exp(0.4), exp(0.5), exp(0.7), exp(0.8)]

It is not clear to me whether the cause of this behavior is an interfering flag, or that the "newer view" that programmer indexing provides of the object is not what subs or eval expects to receive. To my taste, ?rtable_indexing is somewhat obscure.

@williamov 

This is a well known bug of 2D input in Maple 12. Better use 1D input mode.

@williamov 

This is a well known bug of 2D input in Maple 12. Better use 1D input mode.

The chapter 16 of the Programming Guide, subsection 16.5 Creating Efficient Programs > Profiling a Procedure, on the subpackage CodeTools:-Profiling, contains this paragraph:

The older profile facility is also still available but it is slower and does not provide line-by-line profiling information. It is still useful for profiling the use of built-in procedures, which are not supported by CodeTools:-Profiling....

The chapter 16 of the Programming Guide, subsection 16.5 Creating Efficient Programs > Profiling a Procedure, on the subpackage CodeTools:-Profiling, contains this paragraph:

The older profile facility is also still available but it is slower and does not provide line-by-line profiling information. It is still useful for profiling the use of built-in procedures, which are not supported by CodeTools:-Profiling....

The problem here is that the procedure residue contains in line 18 a call to coeff:

> showstat(residue,18);
residue := proc(f, a::(name = anything))
local g, i, t, x, t1;
       ...
  18       return coeff(t,x,-1)
       ...

And coeff expects receiving as first argument a "polynomial" in integer powers of the second argument, but it receives a series data structure:

> trace(coeff):
> residue(1/(2^s-1), s=2*Pi*I*3/log(2));
execute coeff, args = series(1/(2^(6*I*Pi/ln(2))-1)+(-1/(2^(6*I*Pi/ln(2))-1)^2*
ln(2)*2^(6*I*Pi/ln(2)))*s+O(s^2),s,2), s, -1
                                       0

Which returns the same as this toy example:

> coeff(series(1,x,1),x,-1);
                               0

Namely, as a constant:

> coeff(1,x,-1);
                                       0

So, one of the problems with residue is that it has no check for the value of t in that line being a "polynomial" in x.

@casperyc 

Yes, it seems likely a bug, probably in the kernel, but probably not in subs itself: on the one hand the same results (working or not) occur when using eval instead. On the other hand, a trace of subs does not show any evident difference between these two cases. 

The costs of bugs, this is an interesting issue! Say that the objective is set to increase the numbers discovered and fixed bugs before release by a factor n. What would be the amount of resources involved? To what extent it would be directly payable? As market poses a constraint, it means that part of the rest of the costs are payed indirectly by the users...

Well, if this is of some consolation, if confirmed as a kernel bug, it is likely to be fixed soon.

@casperyc 

Yes, it seems likely a bug, probably in the kernel, but probably not in subs itself: on the one hand the same results (working or not) occur when using eval instead. On the other hand, a trace of subs does not show any evident difference between these two cases. 

The costs of bugs, this is an interesting issue! Say that the objective is set to increase the numbers discovered and fixed bugs before release by a factor n. What would be the amount of resources involved? To what extent it would be directly payable? As market poses a constraint, it means that part of the rest of the costs are payed indirectly by the users...

Well, if this is of some consolation, if confirmed as a kernel bug, it is likely to be fixed soon.

@Hiker96 

I do not have Mathematica at hand now. A priori I do not remember of better tools for this purpose. Indeed, I see no hint in the help pages for Times and Product. But you should better check at a Mathematica list. Also, in case that you get an informative answer for yes or no, please report back.

@Hiker96 

I do not have Mathematica at hand now. A priori I do not remember of better tools for this purpose. Indeed, I see no hint in the help pages for Times and Product. But you should better check at a Mathematica list. Also, in case that you get an informative answer for yes or no, please report back.

@Carl Love 

Yes, sadly VerifyTools is still undocumented, I wonder why (the copyright of the verification procedures says 1999). I have not had time yet to explore it thoroughly, but the same as the documented part of the verify facility shows that it was inspired after type, the overall design of its extension mechanism looks roughly similar to that of TypeTools. In particular it exports these procedures:

[VerifyTools:-Verify, VerifyTools:-AddVerification, VerifyTools:-RemoveVerification, 
VerifyTools:-HasVerification, VerifyTools:-GetVerification, 
VerifyTools:-GetVerifications, VerifyTools:-IsFalse, VerifyTools:-IsFail]

And the private table VerifyTools:-VerifyTab shows interesting pieces of code for verification procedures, some of them useful but undocumented also.