If you are going to make multiple posts like this (which you have just done) then please could you either include in each (both title and body) some keyword that informs readers as to the topics covered?

Otherwise, please couldn't you just roll them together in a single post?

What you've done so far is just submit a bunch of separate posts linking to other sites, plus zip files, each with no indication of the subject of content. That's a lot like spam.

acer

I didn't mention `numoccur` because it brings the extra need to match the nature of the zeros. If the Matrix has exact 0 then numoccur needs to be passed exact 0 as the second argument. And similarly for floating point 0.0.

So using `numoccur` can bring an extra burden of knowing what type of zeroes are to be tested, and what kind of data is in the Matrix. Of course, if you know the type of data for sure, or if you wish to distinguish between 0 and 0.0, then it's not an issue.

> M:=Matrix([[0.0, 0.0],[3.0,0.5]]);
                                    [0.     0. ]
                               M := [          ]
                                    [3.0    0.5]

> numboccur(M, 0);                  
                                       0

> numboccur(M, 0.0);                
                                       2

> 4-add(`if`(x<>0,1,0),x=M);        
                                       2

> 4-rtable_num_elems(M,'NonZero');  
                                       2

> M:=Matrix([[0, 0],[3,1/2]]);      
                                     [0     0 ]
                                M := [        ]
                                     [3    1/2]

> numboccur(M, 0);                
                                       2

> numboccur(M, 0.0);              
                                       0

> 4-add(`if`(x<>0,1,0),x=M);      
                                       2

> 4-rtable_num_elems(M,'NonZero');
                                       2

And then the mixed case gets more awkward still.

> M:=Matrix([[0, 0.0],[3,5]]);
                                     [0    0.]
                                M := [       ]
                                     [3    5 ]

> numboccur(M, 0);            
                                       1

> numboccur(M, 0.0);
                                       1

> 4-rtable_num_elems(M,'NonZero'); 
                                       2

> 4-add(`if`(x<>0,1,0),x=M);       
                                       2

acer

I didn't mention `numoccur` because it brings the extra need to match the nature of the zeros. If the Matrix has exact 0 then numoccur needs to be passed exact 0 as the second argument. And similarly for floating point 0.0.

So using `numoccur` can bring an extra burden of knowing what type of zeroes are to be tested, and what kind of data is in the Matrix. Of course, if you know the type of data for sure, or if you wish to distinguish between 0 and 0.0, then it's not an issue.

> M:=Matrix([[0.0, 0.0],[3.0,0.5]]);
                                    [0.     0. ]
                               M := [          ]
                                    [3.0    0.5]

> numboccur(M, 0);                  
                                       0

> numboccur(M, 0.0);                
                                       2

> 4-add(`if`(x<>0,1,0),x=M);        
                                       2

> 4-rtable_num_elems(M,'NonZero');  
                                       2

> M:=Matrix([[0, 0],[3,1/2]]);      
                                     [0     0 ]
                                M := [        ]
                                     [3    1/2]

> numboccur(M, 0);                
                                       2

> numboccur(M, 0.0);              
                                       0

> 4-add(`if`(x<>0,1,0),x=M);      
                                       2

> 4-rtable_num_elems(M,'NonZero');
                                       2

And then the mixed case gets more awkward still.

> M:=Matrix([[0, 0.0],[3,5]]);
                                     [0    0.]
                                M := [       ]
                                     [3    5 ]

> numboccur(M, 0);            
                                       1

> numboccur(M, 0.0);
                                       1

> 4-rtable_num_elems(M,'NonZero'); 
                                       2

> 4-add(`if`(x<>0,1,0),x=M);       
                                       2

acer

Another ungraceful way to do this particular example posed in the Question, at present, is to substitute a single name for Pi*a, then simplify, and then backsubstitute,

restart:
expr := -2*Pi*sin(Pi*a)/(-1+cos(2*Pi*a)):

subs(g=a*Pi,simplify(algsubs(a*Pi=g,expr)));

                              Pi    
                           ---------
                           sin(Pi a)

In principle this workaround should not be necessary as the Pythagorean identity, upon which this particular simplification can hinge, should hold regardless of such a scaling.

acer

Another ungraceful way to do this particular example posed in the Question, at present, is to substitute a single name for Pi*a, then simplify, and then backsubstitute,

restart:
expr := -2*Pi*sin(Pi*a)/(-1+cos(2*Pi*a)):

subs(g=a*Pi,simplify(algsubs(a*Pi=g,expr)));

                              Pi    
                           ---------
                           sin(Pi a)

In principle this workaround should not be necessary as the Pythagorean identity, upon which this particular simplification can hinge, should hold regardless of such a scaling.

acer

This Question leads to the following case which gets overlooked by the simplify command.

restart:

simplify( -1+cos(a)^2 ); # ok

                                   2
                            -sin(a) 

simplify( -1+cos(a*b)^2 ); # ?? missed ??

                                      2
                         -1 + cos(a b) 

simplify( -1+sin(a*b)^2 ); # ok

                                    2
                           -cos(a b) 

If that middle (problem) case above were fixed, so that the Pythagoras identity were recognized and used, then I could envision the submitter's example succeeding more directly. With that bug fixed then just `simplify, or `simplify` after `expand`, might get the desired result.

I will submit a bug report on that middle case above.

It worked fine for me, on 64bit Maple 15.00 or 15.01 each running on 64bit Linux ubuntu 10.04.

Please, let me ask one question though: are you using 2D Math input? Is it possible that you have an extra space between the int and the (...) bracketed piece? I'd just like to eliminate that possibility first, that it might be a case of inadvertant implicit multiplication.

acer

I don't see how this particular type-check that you've assembled in the Criterium [sic] procedure is useful for the described task. How does it distinguish between floats which are purely real and those which are not?

acer

I don't see how this particular type-check that you've assembled in the Criterium [sic] procedure is useful for the described task. How does it distinguish between floats which are purely real and those which are not?

acer

@Markiyan Hirnyk I have changed the Alias(MM,[18]), which did not appear in my version of pvrbik's procedure but was an additional aside, to Alias(MM,[op([1,1],MM)]) in my comment above so that it is more general. One could pick off the first dimension of an mx1 Matrix in several other ways, as well.

I will mention that you too hard-coded the size 18 into your own version above, as opposed to picking off the dimension programmatically.

Was it the combined local declaration and assignment that concerned you? I haven't checked the documentation to see whether it is properly mentioned. Since pvrbik used it before me, in his version, then I tried it out. Recall that it is his code, not mine. I reckoned that if I could figure it out, based on pvrbik's code and accept it, then other people might too. The echoed printing of a procedure below gives some indication as to how it is parsed,

f:=proc(x::list)
   local a,b,
   c:=x[1],
   d:=[c];
return d[1];
end proc;

                             f := proc(x::list)
                             local a, b, c, d;
                               c := x[1];
                               d := [c];
                               return d[1];
                             end proc;

@Markiyan Hirnyk I have changed the Alias(MM,[18]), which did not appear in my version of pvrbik's procedure but was an additional aside, to Alias(MM,[op([1,1],MM)]) in my comment above so that it is more general. One could pick off the first dimension of an mx1 Matrix in several other ways, as well.

I will mention that you too hard-coded the size 18 into your own version above, as opposed to picking off the dimension programmatically.

Was it the combined local declaration and assignment that concerned you? I haven't checked the documentation to see whether it is properly mentioned. Since pvrbik used it before me, in his version, then I tried it out. Recall that it is his code, not mine. I reckoned that if I could figure it out, based on pvrbik's code and accept it, then other people might too. The echoed printing of a procedure below gives some indication as to how it is parsed,

f:=proc(x::list)
   local a,b,
   c:=x[1],
   d:=[c];
return d[1];
end proc;

                             f := proc(x::list)
                             local a, b, c, d;
                               c := x[1];
                               d := [c];
                               return d[1];
                             end proc;

@Markiyan Hirnyk Just run the code in my previous comment in this answer thread; it runs in Maple 13 if properly pasted in a 1D Maple notation code. (It will not work, if pasted as 2D Math input.)

I don't understand what you are saying about parameters; it reads as nonsense to me. You may be having an off week, but please don't take it out on me.

@Markiyan Hirnyk Just run the code in my previous comment in this answer thread; it runs in Maple 13 if properly pasted in a 1D Maple notation code. (It will not work, if pasted as 2D Math input.)

I don't understand what you are saying about parameters; it reads as nonsense to me. You may be having an off week, but please don't take it out on me.

@Markiyan Hirnyk It's extremely easy to fix it for Maple 13. Just swictch around the R and M declaration/assignments, and have the R be done in terms of M rather than MM.

After such an edit, pvbik's code could become,

M := Matrix(18, 1, [2, 3, 3, 5, 7, 8, 12, 5, 9, -3, 4.1, 7, 7, 7, -3, 9, 3, 8]):

MatLabSort := proc( MM :: Matrix ) :: list( Matrix, list );
local  i, Pos,
    SortedMM := table(),
    M := convert( MM, list ),
    R := convert(Statistics[Rank](M),list);
    
    for i from 1 to nops(R) do
        SortedMM[ R[i] ] := M[i];
        Pos[ R[i] ] := i;
    end do;
    
    return [ convert(convert(SortedMM,list),Vector), convert(Pos,list) ];
    
end proc;

MatLabSort( M );

Or one could use Statistics[Rank](ArrayTools:-Alias(MM,[op([1,1],MM)])), to avoid that inefficiency of the list conversion.

@Markiyan Hirnyk It's extremely easy to fix it for Maple 13. Just swictch around the R and M declaration/assignments, and have the R be done in terms of M rather than MM.

After such an edit, pvbik's code could become,

M := Matrix(18, 1, [2, 3, 3, 5, 7, 8, 12, 5, 9, -3, 4.1, 7, 7, 7, -3, 9, 3, 8]):

MatLabSort := proc( MM :: Matrix ) :: list( Matrix, list );
local  i, Pos,
    SortedMM := table(),
    M := convert( MM, list ),
    R := convert(Statistics[Rank](M),list);
    
    for i from 1 to nops(R) do
        SortedMM[ R[i] ] := M[i];
        Pos[ R[i] ] := i;
    end do;
    
    return [ convert(convert(SortedMM,list),Vector), convert(Pos,list) ];
    
end proc;

MatLabSort( M );

Or one could use Statistics[Rank](ArrayTools:-Alias(MM,[op([1,1],MM)])), to avoid that inefficiency of the list conversion.