@Christopher2222 

What holds on the whole complex plane is this equation:

> eq:=ln(1/z)=-ln(z) - 2*I*Pi*unwindK(-ln(z));
                                                   -argument(z) - Pi
          eq := ln(1/z) = -ln(z) - 2 I Pi ceil(1/2 -----------------)
                                                          Pi
> eval(eq,z=-1);
                                  Pi I = Pi I

The value of ceil(...) in the rhs is 0 except on the negative real axis, ie. argument(z)=Pi, where its value is -1.

@baustamm1 

If you mean avoiding the automatic simplification, the answer is no because it is at the core of the system design. All the things that you could do are basically workarounds like the substitution trick.

@acer 

In the case of a numeric upper limit, sum ends up calling add, and then evaluation occurs at the desired point. But for the case of  infinity, there is a "premature" eval stage at SumTools:-DefiniteSum:-Standard line 14:

> kernelopts(opaquemodules=false):
> stopat(SumTools:-DefiniteSum:-Standard,14):
> sum( '`^`'(0,m), m=0..infinity );
`^`(0,x),
x,
0,
infinity
SumTools:-DefiniteSum:-Standard:
  14*    f := eval(f);
DBG> f
`^`(0,x)
SumTools:-DefiniteSum:-Standard:
  14*    f := eval(f);
DBG> into
0
SumTools:-DefiniteSum:-Standard:
  15     x := eval(x)
DBG> quit

So, it might be said that this procedure does not expects receiving such a summand. But a general problem with unevaluation quotes "protection" is predicting how many eval stages the expression will go through.

@casperyc 

Actually, the patterns used by applyrule are, generaicaly, expressions involving parameter type declarations (like a::integer). Pattern parameter bindings occur when the types match. There is an introduction to this subject in ?patmatch, poorly written to my taste though. These parametrized patterns provide the programming power to this tool, somewhat akin to parameters in procedure syntax.

Your inserted images are hard to see. Nevertheless, I guess that your last point is about a pattern in factorized form not matching. If so, again types are the key. For instance, matching an expression that is a sum of two terms requires a pattern of the same type, namely `+`. A pattern in factorized form, of type `*`, will not do, even when mathematically they were equivalent (by distributive law).

This requirement of exact type matching arises because this pattern matcher is largely syntactical. Meaning that it depends on many low level data structure details. Indeed, a true patternmatcher at the higher semantic/mathematical level, independent of such details, is needed.

@taro 

Yes, debugging shows that the plotbuilder interface goes the programmatic way in the background when plotting (it ends up calling the procedure `print/PLOT` as any ordinary plot command does), while menu plot actions do not ( `print/PLOT` seems to be bypassed). So, it is unclear whether the command that the plotbuilder produces fully corresponds to what the menu actions do, but it is a workaround indeed.

Fully agree about the user dealing with limitations of the system as long as these limitations are fully informed. The problem is that very frequently they are not...And also I have been requesting for years, here and elsewhere, proper documentation on the algorithms being used and details of their implementation. 

Yes, I agree with Xavier that a better design would have dummy variables in definite integrals/sums/products, etc represented by local names. I have discussed this issue several times here and elsewhere. For instance in this thread for the case of sums. But sadly, as in many other threads, my comments were removed (censorship?). I keep a local copy of the original thread.

@Thomas Richard 

That input type information in ?LinearAlgebra,LyapunovSolve/SylvesterSolve should be stated clearly at the Matrix items in the section "Parameters". As it stands now, down the section "Description", this critical information is poorly visible.  

@ThU 

Actually I have seen none, and it seems like there was none. Very unusual as dot releases have been announced here for years. For instance, this one for Maple 18.01. And the list of changes in the download page for Maple 18.02 is quite longer than those for 18.01, many of them a priori unrelated to compatibility issues with MapleSim. And even if it were only a compatibility update, not announcing it would be a poor communicational practice all the same. 

PD. The announcement has appeared at last here.

@ThU 

Was there any Maple 18.02 announcement?

@smith_alpha 

What the CLI handles are input plain text files (conventionally saved with termination .mpl), not Standard GUI worksheets (with termination .mw), which are XML format files. So, one option to run the input contained in a worksheet file is to export it to a Maple input file ( File > Export As > Maple Input ).

@chuiko 

Thank you for the pointer. I am not familiar with this subject, except from the patient side... So, just curious, were those 80 measurements made at regular intervals? And what does the main period of about 12 counts mean clinically? By the way, that worksheet contains a significant number of typos.

@nm 

Certainly Maple can, see e.g. ?external_calling and ?ExternalCalling. Actually, a lot of functionality is implemented in external C libraries. That png format is not included is most likely an issue of development priorities. And it has been requested time ago.

@Mac Dude 

Certainly, in general individual actions do not change companies' behavior in any sector, but collective actions may do, as history shows. So, the point is not so much about ranting, understood as a psychological discharge action made in isolation, but of organization as a user community. Meaning that verifying results is necessary but not enough.

@Vrbatim 

Note that ?numtheory,sigma states that the argument has to be type integer. Actually, this procedure checks for its argument being type integer or Not(constant):

> showstat(numtheory:-sigma,1);
numtheory:-sigma := proc(n::Or(integer,Not(constant)))
...

Meaning that it will throw an error for an argument like 1/2 or Pi, but returns unevaluated for a symbol like k:

> numtheory:-sigma(1/2);
Error, invalid input: numtheory:-sigma expects its 1st argument, n, to be of
type Or(integer,Not(constant)), but received 1/2

> numtheory:-sigma(k);
                              numtheory:-sigma(k)

So, evaluation of the summand returns the unevaluated function call numtheory:-sigma(k) in it, for which no information on how it behaves wrt to symbolic k seems available. And the implemented algorithms for finite sums do not handle this summand. Missing that information, this summand, and its unevaluated sum, remain symbolic, as the symbol a say. And the implicit assumption is that a is finite:

> eval(a/N,N=infinity); 
                                       0

So, what should be changed to return something different?