@IanLisle 

I can reproduce here (Maple 17.02 on Linux 32-bit) yours and Carl's variations, while Preben's eval trick did not work for me on a sequence of 10 independent sessions. On the other hand, replacing multiplication with division, it works as expected:

> BlahObject := module()
>     option object;
>     export BlahMethod := proc()
>     local C, d, i,f;
#       eval(f(C[i]*d[i] + C[i], i=1..4),f=add);
#       C[i]*d[i] + C[i];
#       C[i]*d[i] ;
#       C[i]/d[i] + C[i];
>       add(C[i]/d[i] + C[i], i=1..4);
>     end proc;
>   end module;
                       BlahObject := Object<>
> 
> B := Object(BlahObject);
                           B := Object<>
> B:-BlahMethod();
             C[1]          C[2]          C[3]          C[4]
             ---- + C[1] + ---- + C[2] + ---- + C[3] + ---- + C[4]
             d[1]          d[2]          d[3]          d[4]

This fact, together with the difference in behavior from Maple 16 to Maple 17 lead me to think that the new POLY data structure is involved with the cause of this error. Compare the generated DAGs, as shown by dismantle, in Maple 16.02 and 17.02:

Maple 16.02:

> dismantle(C[i]*d[i] + C[i]);
SUM(5)
   PROD(5)
      TABLEREF(3)
         NAME(4): C
         EXPSEQ(2)
            NAME(4): i
      INTPOS(2): 1
      TABLEREF(3)
         NAME(4): d
         EXPSEQ(2)
            NAME(4): i
      INTPOS(2): 1
   INTPOS(2): 1
   TABLEREF(3)
      NAME(4): C
      EXPSEQ(2)
         NAME(4): i
   INTPOS(2): 1

Maple 17.02:

> dismantle(C[i]*d[i] + C[i]);
POLY(6)
   EXPSEQ(3)
      TABLEREF(3)
         NAME(4): C
         EXPSEQ(2)
            NAME(4): i
      TABLEREF(3)
         NAME(4): d
         EXPSEQ(2)
            NAME(4): i
   DEGREES(HW): ^2 ^1 ^1 
   INTPOS(2): 1
   DEGREES(HW): ^1 ^1 ^0 
   INTPOS(2): 1

Certainly, the POLY DAG is not involved in these other expressions that work:

> dismantle(C[i]/d[i] + C[i]);
SUM(5)
   PROD(5)
      TABLEREF(3)
         NAME(4): C
         EXPSEQ(2)
            NAME(4): i
      INTPOS(2): 1
      TABLEREF(3)
         NAME(4): d
         EXPSEQ(2)
            NAME(4): i
      INTNEG(2): -1
   INTPOS(2): 1
   TABLEREF(3)
      NAME(4): C
      EXPSEQ(2)
         NAME(4): i
   INTPOS(2): 1

> dismantle(C[i]*d[i] );
PROD(5)
   TABLEREF(3)
      NAME(4): C
      EXPSEQ(2)
         NAME(4): i
   INTPOS(2): 1
   TABLEREF(3)
      NAME(4): d
      EXPSEQ(2)
         NAME(4): i
   INTPOS(2): 1

However, the POLY DAG is involved in the working variation with a single TABLEREF:

> dismantle(C[i]*d + C[i]);
POLY(6)
   EXPSEQ(3)
      NAME(4): d
      TABLEREF(3)
         NAME(4): C
         EXPSEQ(2)
            NAME(4): i
   DEGREES(HW): ^2 ^1 ^1 
   INTPOS(2): 1
   DEGREES(HW): ^1 ^0 ^1 
   INTPOS(2): 1

So, it seems like the code of Object has problems handling the new POLY DAG when it comes with a pair of TABLEREF (or perhaps more) with "different" names. Note that no problem occurs (at least here) e.g. with  C[i]*C[j]+C[i].

@IanLisle 

OK. The "offending" line is in the definition of the procedure BlahMethod, but the bug, I think, is either in the builtin procedure Object, or in another kernel routine called by Object. Indeed, adding trace(add) shows nothing else, so I think that the builtin procedure add is not being executed. In this sense there is no interaction with add (but I am not sure to understand what you mean by "interaction").

Sadly, only somebody from Maplesoft with access to the kernel code could tell for certain what is the problem when handling this line (which otherwise looks OK, I agree).

@nm 

The same issue as before. Maplesoft management wants to promote the usage of their "wonderful" document mode. But they have not managed to found any sensible way to translate their typeseting scheme to the world of browsers. So, the administrators of this site have received the order to accept image files for 2D input. Then, any amount of complaints would do nothing. And if you would ever see Bryon essaying an answer, I bet he would say that he sees a value in those images...

In these conditions, most often, I just skip any such question.

What proc do you say that is not even being executed? The procedure Object is executed:

> trace(Object):  
> B := Object(BlahObject);  
execute Object, args = module () export BlahMethod; option object; BlahMethod 
:= proc () local C, d, i; add(C[i]*d[i]+C[i],i = 1 .. 4); return NULL end proc;
end module
Execution stopped: Stack limit reached.

@Carl Love 

May be that this help page is not properly updated. From some kind of discussion elsewhere, I have got the impresion that timelimit not only is ignored for kernel routines but also for routines in external compiled libraries. So, it may be that all depends on the fraction of time spent in the library routines vs the fraction of time spent elsewhere. And this distribution may not be known a priori. Actually, unexpected behavior from timelimit occur sometimes.

About the stop button, it is not clear to me its implementation. That is, what it exactly does for stopping. Less, its relation with timelimit. Have you seen any useful documentation on this subject?

@Carl Love 

This exception is actually raised when trying to select from an empty list:

> [][1];
Error, invalid subscript selector

in line 8 of `latex/latex/symbol`. This code seems to assume that it is handling a list of strings, like in this example:

> trace(`latex/latex/symbol`):
> latex(a);
{--> enter latex/latex/symbol, args = a
                                   ent := "a"
                                  ent := ["a"]
                                  texlist := a
                                     ll :=
<-- exit latex/latex/symbol (now in latex/print) = a}

So, the actual bug may be in Typesetting:-EntitySplit which returns NULL for the null string:

> Typesetting:-EntitySplit("",2); 
> Typesetting:-EntitySplit(" ",2); 
                                      " "

So, chances are that this bug has also consequences wherever the Typesetting package is involved (2-D parser, etc);

@Christopher2222 

And does it occur also with earlier versions in that system? What about Classic GUI?

@Carl Love 

Actually I have seen bugs like this one and worst. As I see it, the Standard GUI is too much complex to get even 1D input to work reliably. Compare the XML code of the lines that define vlak2, vlak3, and vlak4, that do not work, with the line that defines vlak1, that works:

 <Text-field style="Normal" layout="Normal"><Font style="Maple Input">    vlak1:=Transpose(Matrix([Column(res,8),Column(res,7),Column(res,9)])):

    <Font executable="false">vlak2:=Transpose(Matrix([Column(res,8),Column(res,7),Column(res,9)]));</Font>
    <Font executable="false">vlak3:=Transpose(Matrix([Column(res,8),Column(res,5),Column(res,9)]));</Font>
    <Font executable="false">vlak4:=Transpose(Matrix([Column(res,5),Column(res,6),Column(res,9)]));</Font>

    pp1:=polygonplot(vlak_onder):
    pp2:=polygonplot(vlak_links):
    pp3:=polygonplot(vlak_voor):
    pp4:=polygonplot(vlak_rechts):
    pp5:=polygonplot(vlak_achter):
    pp6:=polygonplot(vlak_boven);
    pp7:=polygonplot(vlak1);
    pp8:=polygonplot(vlak2);
    pp9:=polygonplot(vlak3);
    pp10:=polygonplot(vlak4);</Font></Text-field>




Note that the Text-field tag opened at the first line is not closed until much later, at the end of the line defining pp10. I do not see any good reason why these three lines are not of the same syntax of the first one (actually opening and closing the Text-field tag for every line). Anyway, I have edited a copy of the original worksheet, just changing the label "false" to "true" in these three lines, saved and run it without further error, so that a polygon plot was produced.

@Carl Love 

By the way, this is another good example of inconsistency in the documentation:  in "The combine function" and "the expand function" function is used in the sense of procedure or routine. And note that the same paragraph begins with "For many functions" where function is used either in the sense of function call or mathematical function. So that the writer of this help page, probably the developer of combine, has/had some mental problem...

And to the point of this thread, "For many functions" is poor documentation, as the user cannot deduce from that statement for which functions expand and combine are "inverses" (applying the identity in inverse sense), and for which they are not. Certainly, they are not for the identity here sin(x)^2 = 1/2 - 1/2 cos(2 x).

In my opinion, a sensible design should provide inverse commands (in the sense defined above) for every implemented identity.

@pagan 

This is one way, I do not know if the best:

> z:=op(indets(others[1],'suffixed(_Z, integer)'));
                                   z := _Z1~
> s:=solve(others[1],z);
Warning, solve may be ignoring assumptions on the input variables.
                                          2
                                         x  - 2 x + 1
                       s := {_Z1~ = - ------------------}
                                            2
                                      2 (2 x  - 2 x + 1)
> solve(s,x,parametric,real);
    {                        []                                _Z1~ <= -1/2
    {
    {       2 _Z1~ + 1 + %1          -2 _Z1~ - 1 + %1
    { [[x = ---------------], [x = - ----------------]]        _Z1~ < -1/4
    {         4 _Z1~ + 1                4 _Z1~ + 1
    {
    {       2 _Z1~ + 1 + %1          -2 _Z1~ - 1 + %1
    { [[x = ---------------], [x = - ----------------]]          _Z1~ < 0
    {         4 _Z1~ + 1                4 _Z1~ + 1
    {
    {                     [[x = 1]]                              _Z1~ = 0
    {
    {                        []                                  0 < _Z1~
                                        2          1/2
                          %1 := (-4 _Z1~  - 2 _Z1~)
> is(%1::real) assuming z::integer;
                                     false

@nm 

Welcome to the wonderful world of Maple GUI :)

@nm 

An easier way may be exporting to a  Maple input .mpl file, and then importing it into the GUI, now creating a worksheet. The result must be checked as 2D input parser bugs may hit.

@nm 

No, this is not what designers of the GUI have in mind. Certainly, I have the same preferences as you and so I use Maple mostly from the Medit IDE like editor, which provides precisely this kind of interface. See the screenshot here (note that there is regression bug in this site, as the link may send to the top of the thread, so that you have to scroll down manually).

@nm 

Not any better using Firefox or Chrome on Linux. Curiously the same help page with a strange issue reported here...

I would find hard to believe that Maplesoft managers have not paid a look at these "New Features" help pages. I find more likely that the problem is staff scarcity in relation to the amount of work, which is being streched beyond reasonable, making simple fixes take too long, as this site shows.

Lenin, inversa va con "s".