acer

32632 Reputation

29 Badges

20 years, 45 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by 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.

It would be better without the conversion of M to an Array, via list conversion. That's a double copy, with both as unnecessary inefficiencies.

In Maple 15 and 16, the Statistics:-Rank function accepts the 18x1 Matrix. But that won't work in all older versions, such as Maple 13 for example.

In Maple 13 (and later) you could do it like this and avoid that data copying,

restart: interface(rtablesize = 20):
M := Matrix(18, 1, [2, 3, 3, 5, 7, 8, 12, 5, 9, -3, 4.1, 7, 7, 7, -3, 9, 3, 8]);
with(Statistics):
A:=ArrayTools:-Alias(M,[18]);
R := Rank(A);
OA := OrderByRank(A, R);
NR := OrderByRank(Array([`$`(1 .. 18)]), R);
[OA, NR];

acer

It would be better without the conversion of M to an Array, via list conversion. That's a double copy, with both as unnecessary inefficiencies.

In Maple 15 and 16, the Statistics:-Rank function accepts the 18x1 Matrix. But that won't work in all older versions, such as Maple 13 for example.

In Maple 13 (and later) you could do it like this and avoid that data copying,

restart: interface(rtablesize = 20):
M := Matrix(18, 1, [2, 3, 3, 5, 7, 8, 12, 5, 9, -3, 4.1, 7, 7, 7, -3, 9, 3, 8]);
with(Statistics):
A:=ArrayTools:-Alias(M,[18]);
R := Rank(A);
OA := OrderByRank(A, R);
NR := OrderByRank(Array([`$`(1 .. 18)]), R);
[OA, NR];

acer

@Markiyan Hirnyk He posted plaintext, not 2D Math in a worksheet. Your mistake is in pasting it -- as is -- into the Standard GUI while in 2D Math mode. This code is an example of how the two parsers can differ. The source he posted is valid 1D Maple notation source (for Maple 15 and 16, at least), but it cannot be successfully run after being just pasted into the Standard GUI in 2D Math input mode.

The difference lies in how the 2D parser fails to handle the local variables' combined declaration/assignments (also split across lines). See here for an old post about some such differences.

If pasted as plaintext souce code into a Maple 15 or 16 interface prepared for 1D Maple notation source code then it runs.

First 410 411 412 413 414 415 416 Last Page 412 of 597