Note that one can generally ony display colors from what is displayable within the RGB colorspace, which is a smaller triangular region within the visible gamut of the CIE xyY colorspace (which you seem to be constructing).

But it's possible to get an approximation of the visible xyY gamut by shading the non-displayable points with colors obtained by regressing back to the edge of the displayable RGB gamut. Below, this is attempted for the given xy points (presumed as some approximation of the edge of the xyY gamut -- let me know it that's not right).

The final plot does not look fuzzy when run in my Maple 18 Standard GUI. I have used at least one command new to Maple 18 (ColorTools:-ToDisplayable), so this code wouldn't work in an earlier version.

In the followup interpolation I also added the line of purples to what I presume you intend as the spectral color edge.

Download cie_xyY_gamut.mw

A nice task would be to use Maple to produce an ImageTools image or a densityplot, with the whole gamut shaded.

acer

restart:

FF := Q-1+(1/5)*K*dp^3*h^5+(1/3)*dp*h^3+h+h1*h:
DDP:=[solve(FF,dp)]:
h:=1+phi*cos(2*Pi*x):
h1:=2*Pi*alpha*beta*phi*cos(2*Pi*x):
beta:=1:alpha:=0:
phi:=0.5:
dpdx:=evalf(DDP[1]):
dpp:=Int(Re(dpdx),x=0..1):

plot([subs(K=-0.1,dpp)],Q=-1..1,axes=box,color=[blue]);

acer

The answer is not the one you expected, but it is not completely invalid. Degrees can represent an absolute or a relative scale.

A temperature of 32.0 degC is the same as a temperture of 89.6 degF.

But if the temperature is increased by 32.0 degC then it is increased by 57.6 degF.

The context menu does the latter conversion. Perhaps it could be augmented with a way to do either.

convert( 32.0*Unit(degC), units, degF);

                57.60000000 Units:-Unit('degF')

convert( 32.0*Unit(degC), temperature, degF);

                 89.6000000 Units:-Unit('degF')

acer

Could you not transform the plots with cartesian coordinates?

Download polarde.mw

acer

eval(irem(m,4),m=21);

                               1

eval('`mod`'(m, 4), m=21);

                               1

Even if you were to obtain an unevaluated return from the call `mod`(m,4), then you'd still need an evaluation after substituting with `subs`.

acer

The time for the rank computation should dwarf time for the (uniform dist.) random float[8] Matrix creation as the dimension n gets large. So the two operations should have their timings done separately.

And CodeTools:-Usage is a more convenient way to demonstrate the performance in later Maple versions, IMHO.

I am seeing better results for LinearAlgebra:-Rank on float[8] Matrices in Maple 18.01 on 64bit Linux.

On 64bit MS-Windows I see Rank performing as in 18.00, although LinearSolve and MatrixInverse do a bit better better than in 18.00.

acer

Your original attempt is not so bad, and I believe you can get it to work without having to make temporary substitutions for `a` and `z`. But you did forget to map the `limit` command when assigning to H, since expr2 will also be a Vector.

Note that your post contained the invalid syntax,

  phi := -> z (l*z+a)/(1-l*conjugate(a)*z):

Was you intention that it instead be,

  phi := z -> z*(l*z+a)/(1-l*conjugate(a)*z):

or,

  phi := z -> (l*z+a)/(1-l*conjugate(a)*z):

I'll use the former, as Markiyan has. Using the latter and Omega becomes not just the zero-Vector.

> restart:    

> omega := z -> 2*<Re(z), Im(z), 1>/(1+abs(z)^2):
> phi := z -> z*(l*z+a)/(1-l*conjugate(a)*z):
> expr := omega(phi(1/e)):

> Omega := simplify(map(limit, expr, e = 0)) assuming l::real;

                                          [0]
                                          [ ]
                                 Omega := [0]
                                          [ ]
                                          [0]

> expr2 := (omega(phi(1/(e^2*conjugate(z))))-Omega)/e^2:

> H := simplify(map(limit, expr2, e = 0)) assuming l::real;

                               [       1     _2 _2  ]
                               [-2 Re(---) | z  a  |]
                               [      _ _           ]
                               [      z a           ]
                               [                    ]
                          H := [       1     _2 _2  ]
                               [-2 Im(---) | z  a  |]
                               [      _ _           ]
                               [      z a           ]
                               [                    ]
                               [         0          ]

I haven't yet been able to get Maple to simplify the difference of these two scalar expressions to zero, unless I substitute and evalc.

T1 := Im(a)*Im(z)-Re(a)*Re(z):

T2 := -Re(1/(conjugate(z)*conjugate(a)))*abs(conjugate(z)^2*conjugate(a)^2):

I obtained T1 in the result obtained with substituting fore and aft for `a` and `z` as Markiyan did.

acer

Are you saying that you know the nature of x at some juncture, and you want to find out what `f` will become there? Eg,

restart:

f := piecewise(x>0,1+x,x=0,2,x<0,1+x^2):

expr1 := eval(f) assuming x>0;

                             1 + x

expr2 := eval(f,x=0);

                               2

expr3 := eval(f) assuming x<0;

                              2    
                             x  + 1

Or do you need to extract out both the conditions and the subexpressions from `f` (which possibly you did not create yourself). For that you can use `op`, or indexed into it as a list. Eg,

flist := convert(f,list);

            [                                2    ]
            [0 < x, 1 + x, x = 0, 2, x < 0, x  + 1]

flist[1];

                             0 < x

flist[2];

                             1 + x

# ...and so on

Of course, if you built `f` yourself, explicitly, then you could simply assign the various conditions and pieces to names, beforehand. Eg,

restart:

cond1:=x>0:
expr1:=1+x:
cond2:=x=0:
expr2:=2:
cond3:=x<0:
expr3:=1+x^2:

f:=piecewise(cond1,expr1,cond2,expr2,cond3,expr3);

acer

restart; 
vvv:=n^2+3*m:
g:=(n,m)->vvv:

g(1,1);

                             2      
                            n  + 3 m

g:=unapply(vvv,[n,m]):

g(1,1);
                               4

Spamming this site by posting the same issue multiple times is irritiating. Please stop doing that. It's not the first time.

acer

How about something with `applyrule`, such as say,

  map2(applyrule, d^(n::And(posint,satisfies(t->t>=2)))=0, myeq);

I realize that `applyrule` is a command in the Library of interpreted procedures and not a compiled kernel builtin. I had the idea that by "builtin" you meant something else.

acer

The meaning of %1 and related formatting parameters is explained on the error help-page.

The syntax for such parameters in the message string is somewhat similar to the formatting modifiers used in printf, but they are not the same and the explanation will not be obtained simply by looking at the printf help-page.

acer

You can use `rsolve` here, to solve for the general term a(n). And you can use that to produce either a recursive procedure or an expression (in terms of n) for the result.

Note that with this approach you don't first have to adjust (manually) the indices to obtain a(n) = a(0) + a(n-1).

eq := a(n+2) = a(0) + a(n+1):                     

f := rsolve( {subs(a(0)=1,eq), a(0)=1}, a(n), makeproc ):

f(4);                                                    

                                       5

expr:=rsolve( {subs(a(0)=1,eq), a(0)=1}, a(n) );         

                                 expr := n + 1

eval(expr, n=4);                                         

                                       5

It would be nicer if rsolve({eq,a(0)=1},a(n)) worked directly.

acer

You can evaluate your various expressions (psi[1], etc) at the point x=0 without having to assign (or later unassign) to x.

> expr:=A*cos(x)+ R*i*sin(x) = B*exp(-x)+ C*exp(x):

> solve( eval(expr,x=0) );

                           {A = B + C, B = B, C = C}


> expr;

                 A cos(x) + R i sin(x) = B exp(-x) + C exp(x)

Of course that particular example is trivial and doesn't require using `solve`, because,

> eval(expr,x=0);

                                   A = B + C

acer

Simplification with side relations (which Markiyan demonstrates in another Answer) can be an easy way to get such an effect. It's a good answer.

But it can also be noted that there are times and other examples when some of the simplifications done to an expression might not be what is wanted. Consider the case that the input expression is conjugate(z)*z^2*(ln(2*z) and one wishes to replace conjugate(z)*z while also leaving ln(2*z) intact. In other words, the following might not be what is wanted,

simplify( conjugate(z)*z^2*(ln(2*z)), {z*conjugate(z)=x} );

                           (ln(2) + ln(z)) x z

And of course there are related problematic examples where some undesired aspect of simplification is not easily undone after the fact (with `combine` or what have you). In other words, the need for (only) plain substitution is not obviated by fixing the above simplistic example by calling something like `combine` on the result.

So it might be that for some examples one wants just the substitution. And `algsubs` goes awry trying to figure out where and whether z*conjugate(z) is "present". So it's natural to still ask whether `applyrule` could work here.

A difficulty is that `applyrule` does not see z*conjugate(z) as being present within conjugate(z)*z^2 say, and other related situations. An alternative for the rule used might be,

T:=ee->applyrule(z^(m::posint)*conjugate(z)^(n::posint)
                 = x*z^(m-1)*conjugate(z)^(n-1),ee):

And a few rudimentary examples to compare with the simplification with side effects might include,

R:=ee->simplify(ee,{z*conjugate(z)=x}):

f1:=conjugate(z)^2*z^2:
T(f1), R(f1);

                              2   2
                             x , x 

T(conjugate(z)*z^2), R(conjugate(z)*z^2);

                            x z, x z

T(conjugate(z)^5*z^2), R(conjugate(z)^5*z^2);

                              3      3
                           2 _    2 _ 
                          x  z , x  z 

T(conjugate(z)/z^2), R(conjugate(z)/z^2); # no change expected
                             _   _ 
                             z   z 
                             --, --
                              2   2
                             z   z 

But now we might notice that the above does not handle the case where the z*conjugate(z) appears in the denominator. We could try and clean that up crudely, by just repeating the process.

T:=ee->applyrule(z^(m::negint)*conjugate(z)^(n::negint)
                 = 1/(x/(z^(m+1)*conjugate(z)^(n+1))),
                 applyrule(z^(m::posint)*conjugate(z)^(n::posint)
                           = x*z^(m-1)*conjugate(z)^(n-1),ee)):

T(1/(conjugate(z)*z^2)), R(1/(conjugate(z)*z^2));

                             1    1 
                            ---, ---
                            x z  x z

T(1/(conjugate(z)^2*z^3)), R(1/(conjugate(z)^2*z^3));

                            1     1  
                           ----, ----
                            2     2  
                           x  z  x  z

And we can see how the two approaches differ with respect to leaving other terms unchanged (or not), for the example previously mentioned,

expr:=conjugate(z)*z^2*(ln(2*z)):
T(expr), R(expr);

                x z ln(2 z), (ln(2) + ln(z)) x z

It's unfortunate that `applyrule` is not as robust and easy to use as it might be, since it does seem to fulfil at least some needed functionality. (I would not be very surprised if the usage examples I gave above fall down on some related, problematic examples.)

acer

Maple 18 can export 3D surface plots to STL (Stereolithography) file format, which some 3D printers might support directly. (Or you may be able to convert from STL to .x3g format.)

acer