@Alejandro Jakubi Yes, indeed. And that flexible procedure can also be applied to manipulate just the sign (or not).

restart:

dividend:=proc(ex,f:=numer(ex),t:=[expand,expand])
local n,d;
n:=t[1](numer(ex)/f):
d:=t[2](denom(ex)/f);
n/d;
end proc:

s:=-(x+y)/(x+y-1);

                              x + y  
                          - ---------
                            x + y - 1

dividend(s,sign(numer(s)),
         [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                             x + y  
                           ---------
                           1 - y - x

s:=(x+y)/(x+y-1);

                             x + y  
                           ---------
                           x + y - 1

dividend(s,sign(numer(s)),
        [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                             x + y  
                           ---------
                           x + y - 1

s:=-x/(x-1);

                                x  
                            - -----
                              x - 1

dividend(s,sign(numer(s)),
         [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                               x  
                             -----
                             1 - x

s:=x/(x-1);

                               x  
                             -----
                             x - 1

dividend(s,sign(numer(s)),
         [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                               x  
                             -----
                             x - 1

I find the above sign adjustments somewhat pleasing, collectively -- it leaves it alone or not. And the very same command can work for each case. And I'm sure that there are other (different, better, etc) uses of that `dividend` procedure.

@Doug Meade With 2D Math input an operator can be created and assigned using the syntax q(t):=...

In 2D Math mode, by default that causes a disambiguation popup menu to appear, offering the choice to parse as either function definition or remember-table assignment. The default behaviour can even be controlled as a typesetting option. See `functionassign` option on this help-page.

I think that it is wrong behaviour that upon choice of "function assignment" the GUI does not replace such input with q:=t->... and in so doing make the input unambiguous and also valid for 1D.

If I may mention one more variant,

restart:

A:=Matrix([[1,2],[2,3]]):
B:=Vector([x1,x2]):
C:=Vector([c1,c2]):

Equate( A.B+C, Vector([0,0]) );

           [x1 + 2 x2 + c1 = 0, 2 x1 + 3 x2 + c2 = 0]

acer

If I may mention one more variant,

restart:

A:=Matrix([[1,2],[2,3]]):
B:=Vector([x1,x2]):
C:=Vector([c1,c2]):

Equate( A.B+C, Vector([0,0]) );

           [x1 + 2 x2 + c1 = 0, 2 x1 + 3 x2 + c2 = 0]

acer

It might be of interest to you that Maple 16's garbage collector can return collected memory to the OS. In Maple 15 and earlier, that would only happen upon restart. In other words, in Maple 16 kernelopts(bytesalloc) can decrease, without restart.

The garbage collector in Maple 16 is new. It needs a few tweaks, but overall it seems like a Good Thing. For example, there is a measurable speedup between M15 and M16 on some of those comparative performance tests that you recently posted about, and I believe that the new memory management system is due part credit. Those tests do things like floating-point linear algebra on Matrices up to size 2000, iterated several times, all in the same session.

acer

It might be of interest to you that Maple 16's garbage collector can return collected memory to the OS. In Maple 15 and earlier, that would only happen upon restart. In other words, in Maple 16 kernelopts(bytesalloc) can decrease, without restart.

The garbage collector in Maple 16 is new. It needs a few tweaks, but overall it seems like a Good Thing. For example, there is a measurable speedup between M15 and M16 on some of those comparative performance tests that you recently posted about, and I believe that the new memory management system is due part credit. Those tests do things like floating-point linear algebra on Matrices up to size 2000, iterated several times, all in the same session.

acer

@Adri van der Meer Sorry, perhaps I didn't notice that V was constructed by reading along columns of M. So naturally you would want to reconstruct it by laying down entries from Vector V in the same way.

Is this a fix-up, to lay down the Matrix, columnwise, from given Vector V with that interpretation?

Gr:=(m,n,W) -> Matrix(m,n,
                     (i,j)->`if`(i>j, 0,
                                 W[((j-1)*(j)/2)-`if`(j>m,
                                                     (j-m-1)*(j-m)/2, 0)+i])):

I would guess that a do-loop could be faster than such an indexing function due to the hit from calling `if`(i>j,...) on all entries (because with nested loops the upper value for the inner loop's index can be a function of the outer loop's index). And indeed, your procedure performs faster.

@Adri van der Meer Sorry, perhaps I didn't notice that V was constructed by reading along columns of M. So naturally you would want to reconstruct it by laying down entries from Vector V in the same way.

Is this a fix-up, to lay down the Matrix, columnwise, from given Vector V with that interpretation?

Gr:=(m,n,W) -> Matrix(m,n,
                     (i,j)->`if`(i>j, 0,
                                 W[((j-1)*(j)/2)-`if`(j>m,
                                                     (j-m-1)*(j-m)/2, 0)+i])):

I would guess that a do-loop could be faster than such an indexing function due to the hit from calling `if`(i>j,...) on all entries (because with nested loops the upper value for the inner loop's index can be a function of the outer loop's index). And indeed, your procedure performs faster.

@jjrohal As mentioned, you might also consider using Vectors instead of lists.

restart:
<1|2> + <3|4>*(x-1)^2;

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

Vector[row]([1,2]) + Vector[row]([3,4])*(x-1)^2;

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

ee := [1,2] + [3,4]*(x-1)^2:

evalindets(ee,list,convert,Vector[row]);

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

@jjrohal As mentioned, you might also consider using Vectors instead of lists.

restart:
<1|2> + <3|4>*(x-1)^2;

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

Vector[row]([1,2]) + Vector[row]([3,4])*(x-1)^2;

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

ee := [1,2] + [3,4]*(x-1)^2:

evalindets(ee,list,convert,Vector[row]);

                      [             2               2]
                      [1 + 3 (x - 1) , 2 + 4 (x - 1) ]

@Christopher2222 There is this rebuttal to that Wolfram article (linked from here fwiw).

@Alejandro Jakubi Yes, you are quite right that this is much less likely to work than, say, mixing 32bit Classic with 64bit kernel of the same major release. And new or change DAG ids is just the sort of rare change that can make it fail.

I tried to take the tone that it would be interesting to see what results the Asker might have, and that my curiosity there was more my motivator. I wasn't trying to advocate than anyone take this approach on the grounds that it is expected to resolve problems. Apologies, if I didn't make that clear enough.

Of course one would naturally expect that the Classic GUI actually shipped with a major release should be the best and most stable Classic instance to work with that release. There is a slim chance that it may not be, and if so then I think that it's worthwhile to find out. Are the Asker's crashes due entirely to problems introduced into some change in Classic's binary executable (or mclient.dll)? Or are they due to problems communicating with the kernel (eg. new DAG issues, etc)? 

I have been seeing some sudden, random crashes in the Maple 16.01 Standard GUI, doing nothing but repeating many times some simple plots of short amounts of data read from file. I have not been able to construct any way to reproduce this problem on demand, but when it happens all session data is lost. There is a (small) possibility that the problems lies with interface-kernel communication or memory management. Maybe it's related to this Classic problem,... and more likely it is not.

@Alejandro Jakubi Yes, you are quite right that this is much less likely to work than, say, mixing 32bit Classic with 64bit kernel of the same major release. And new or change DAG ids is just the sort of rare change that can make it fail.

I tried to take the tone that it would be interesting to see what results the Asker might have, and that my curiosity there was more my motivator. I wasn't trying to advocate than anyone take this approach on the grounds that it is expected to resolve problems. Apologies, if I didn't make that clear enough.

Of course one would naturally expect that the Classic GUI actually shipped with a major release should be the best and most stable Classic instance to work with that release. There is a slim chance that it may not be, and if so then I think that it's worthwhile to find out. Are the Asker's crashes due entirely to problems introduced into some change in Classic's binary executable (or mclient.dll)? Or are they due to problems communicating with the kernel (eg. new DAG issues, etc)? 

I have been seeing some sudden, random crashes in the Maple 16.01 Standard GUI, doing nothing but repeating many times some simple plots of short amounts of data read from file. I have not been able to construct any way to reproduce this problem on demand, but when it happens all session data is lost. There is a (small) possibility that the problems lies with interface-kernel communication or memory management. Maybe it's related to this Classic problem,... and more likely it is not.

@Adri van der Meer The custom do-loop can be faster, but just for fun,

G:=(m,n,W) -> Matrix(m,n,(i,j)->`if`(i>j,0,W[(i-1)*n-((i-1)*(i)/2)+j])):

G(4,6,V);

@Adri van der Meer The custom do-loop can be faster, but just for fun,

G:=(m,n,W) -> Matrix(m,n,(i,j)->`if`(i>j,0,W[(i-1)*n-((i-1)*(i)/2)+j])):

G(4,6,V);