@Sergio Parreiras 

Note that there is also PDEtools:-Solve.

@ecterrab 

I observe this issue in the Classic and Standard GUIs on Linux 32-bit, but not in the CLI. The same in any Maple 17 dot version, and not in any earlier one. So, there should be an interface interaction introduced in Maple 17. Here, the macro command fixes it.

This interface interaction is clearly observable by following  the TCP conversation between the kernel and the interface through localhost. The exchange is very different when using the CLI and when using the GUIs. This is particularly explicit when running the code in the Standard GUI, showing how the computation flow is redirected to the Java kernel. So, all the evidences show that the origin of this issue is in Java code. Note also that Maple on the Mac uses OS Java, instead of its own version as in the other platfoms. This difference may explain why this issue is not observable in Standard on the Mac.

Perhaps because the stripping and controled evaluation process that Edgardo has described here, cannot be implemented (at least easily) on procedure bodies.

Perhaps because the stripping and controled evaluation process that Edgardo has described here, cannot be implemented (at least easily) on procedure bodies.

I observe also a numerical noise pattern back to Maple 9.03. So, I do not think that smatview has much to do in this one. Rather, what I observe is a change in the pattern from versions <=13.02 to >=14.01.

@viraghj 

I wonder which are those typesetting books. On the contrary, all the typesetting documentation that I know for books and journals state that numbers should be typeset upright in math context. Indeed, this is what TeX is doing in the plot label that I have shown above.

@viraghj 

I wonder which are those typesetting books. On the contrary, all the typesetting documentation that I know for books and journals state that numbers should be typeset upright in math context. Indeed, this is what TeX is doing in the plot label that I have shown above.

@ecterrab 

Time ago I needed precisely a routine doing this job. And being unaware of this routine `assuming/set_expression`, as it is documented nowhere, I spend some time writing a prototype, but probably it was left aside as my time run out. So, I do beleive that users may benefit sometimes of knowing about such a thing.

In my opinion, the need to "reinvent the wheel" just because of undocumentation, looks like a waste of effort on both sides (developers and users).

I do feel that my question about the statement in ?seq is within the scope of this post. Specifically, does the same recommendation of always explicitly declare the index variable to be local inside procedures hold also for this new routine?

By the way, as a side comment, it happens that these days I am precisely investigating the case of some not-user-level-documented library internal routines that cannot be inspected, traced or debugged by ordinary means. Indeed, they look a priori as an exception but it is worrying.

The mdcs debugger is useful for catching this call stack overflow as it occurs (here stopping it when stacklevel >1000), showing that IntegerSub keeps mapping itself over the expression:

mdc:-Skip('stacklevel' = 1000): 
mdc(sum): 
sum(a[1/k],k=1..n);
...
sum
(*1*) if type(f,{'set', 'array', 'list', 'rtable'}) then
skip predicate satisfied: stack level [1009] exceeded 1000
IntegerSub
(**) where
... 
IntegerSub: return map(IntegerSub,term) 
▶ [a[1/(k+1)]] 
IntegerSub: return map(IntegerSub,term) 
▶ [a[1/(k+1)]] 
IntegerSub: return map(IntegerSub,term) 
▶ [a[1/(k+1)]] 
...

@dabarry 

I agree. Sage is much better in this area, providing TeX typesetting of labels, e.g.:

plot(x^2,(x,-5,5),color='black',axes_labels=['$s$','$-1/\\beta-Kb$'],fontsize=25)

@dabarry 

I agree. Sage is much better in this area, providing TeX typesetting of labels, e.g.:

plot(x^2,(x,-5,5),color='black',axes_labels=['$s$','$-1/\\beta-Kb$'],fontsize=25)

@ecterrab 

This hybrid evaluation model that you have described for add is almost surely the same for seq. Now, ?seq states a somewhat curious recommendation:

Note: The index variable i is NOT private to the seq invocation.  It is recommended that you always explicitly declare the index variable to be local inside procedures.

As the reason for this recommendation is not provided, that is what could happen if the index variable were not declared local, I wonder whether you have any comment.

I have met this problem quite frequently when using the Standard GUI since it was launched a decade ago. I have read many complaints from users about this and other GUI problems along the years. In the current situation, where Maplesoft keeps a closed door about developing an alternative, better GUI, the only action for correction available to the users, is keep making "noise" as loud as possible.

@ecterrab 

You have been clear about the hybrid approach. Just note that I have used quotes in "conversion". As everybody knows, it  implies a metaphorical usage (actually standing for the process that you have explained in so full detail).  

On the other hand, I think that it might be convenient for the user to get simple access to this stripping routine for controled evaluation.

@ecterrab 

Once again: a local dummy approach requires an adapted set of tools, which are not available in current Maple (and probably they will never be there). In your example ee:=f(j); sum(ee,j=1..3), it implies that the global j in ee has to be converted to the local j used as the dummy for the sum to work as desired. This requires, on the one hand a syntactic marker given by the user, stating explicitly that he wants j in ee be interpreted as the dummy, and some parsing/evaluation rules performing the conversion. I consider that an explicit declaration would be better as there would be no ambiguity left.

The hybrid approach, on the other hand, makes the "conversion" implicitly, meaning that it does not require any explicit declaration by the user, And, as you say, it may work in current Maple as is (well, it does for add, you say that, mutatis mutandis, it does also for sum). The second point is clearly an advantage as it allows quicker development, and you did it already. My concern is about the implicit (automatic) conversion. My feeling is that it may produce an inconsistency. It is a feeling at this point as I have not investigated this issue any further.

So, I am not saying that the local dummy approach is the way to go in Maple as things are now. Rather, I am saying that it is a pitty that it was not implemented from scratch. Or, that it should be the way in a future, better system