You have errant multiplication between `Vector` and the left (opening) bracket that follows it. That mistake happens in two places.

Also, you are lacking multiplication between `a` and `v`, and between `b` and `v`, in the first argument passed to NonlinearFit. Add `*` to both of those.

acer

You asked for expand( (a+4)^4 ) not expand( (a+b)^4 ).

Why do you expect to see `b` in the result? What do you see as being inconsistent?

Terms like 4^4 will produce results such as 256 automatically. It is possible, however, to produce things like this,

frontend(expand,[(a+``(4))^4] );

                    4         3           2  2           3    4
                 (4)  + 4  (4)  a + 6  (4)  a  + 4  (4) a  + a

expand(%);                      

                        4       3       2
                       a  + 16 a  + 96 a  + 256 a + 256

acer

@Markiyan Hirnyk 

Finance:-DayOfWeek("November 09, 1885");

                             Monday

Finance:-DayOfWeek("July 27, 2014");
                             Sunday

kernelopts(version);

             Maple 18.01, X86 64 WINDOWS, Mar 28 2014, Build ID 935137

The poster's characterization of a leap year is not usual. The post barely describes an algorithm, let alone a program.

@adel-00 

sol:=solve({32*x+13*y+42*z=50,87*x+190*y+112*z=940,
            10*x+10*y/4+10*z=10},{x,y,z});         

                                1548      3232      -2473
                    sol := {x = ----, y = ----, z = -----}
                                3115      623       3115

f:=4*x+5*y:                                        

eval(f, sol);                                     

                                     86992
                                     -----
                                     3115

@wenny There's not much point is having Maple attempt symbolic integrals it cannot do, so I just changed some of the int calls to Int calls.

I suppose that you are sure of your ranges. The result isn't so exciting, perhaps, with tau2 and t2 producing an optimal objective value (over their ranges as stated) at end points of their ranges.

restart:
with(linalg): with(stats): with(plots): with(Statistics):
with(LinearAlgebra): with(Optimization):
lambda0 := proc (t) options operator, arrow; gamma0+gamma1*t+gamma2*t^2 end proc:
lambda := lambda0(t)*exp(beta*s):
t1 := 145: t3 := 250: #t2 := (t1+t3)*(1/2):
s := 1/(273.16+50): s1 := 1/(273.16+t1): s3 := 1/(273.16+t3):
s2 := 1/(273.16+t2): gamma0 := 0.1e-3: gamma1 := .5: gamma2 := 0: beta := -3800:
c := 300: n := 200:
Theta := solve(1-exp(-(gamma0*tau1+(1/2)*gamma1*tau1^2+(1/3)*gamma2*tau1^3)*exp(beta*s1))
               = 1-exp(-(gamma0*a+(1/2)*gamma1*a^2+(1/3)*gamma2*a^3)*exp(beta*s2)), a):
a := Theta[1]:
Delta := solve(1-exp(-(gamma0*(a+tau2-tau1)+(1/2)*gamma1*(a+tau2-tau1)^2
               +(1/3)*gamma2*(a+tau2-tau1)^3)*exp(beta*s2))
               = 1-exp(-(gamma0*b+(1/2)*gamma1*b^2+(1/3)*gamma2*b^3)*exp(beta*s3)), b):
b := Delta[1]:
A1 := `assuming`([unapply(int(exp(beta*s1)*exp(-(gamma0*t+(1/2)*gamma1*t^2
                              +(1/3)*gamma2*t^3)*exp(beta*s1))
                              /(gamma0+gamma1*t+gamma2*t^`2`), t = N .. M), N, M)],
                 [N > 0, M > 0]):
A2 := unapply(Int(exp(beta*s2)*exp(-(gamma0*(a+t-tau1)
                  +(1/2)*gamma1*(a+t-tau1)^2
                  +(1/3)*gamma2*(a+t-tau1)^3)*exp(beta*s2))
                  /(gamma0+gamma1*(a+t-tau1)+gamma2*(a+t-tau1)^2), t = N .. M), N, M):
A3 := unapply(Int(exp(beta*s3)*exp(-(gamma0*(b+t-tau2)
                  +(1/2)*gamma1*(b+t-tau2)^2
                  +(1/3)*gamma2*(b+t-tau2)^3)*exp(beta*s3))
                  /(gamma0+gamma1*(b+t-tau2)+gamma2*(b+t-tau2)^2), t = N .. M), N, M):
B1 := `assuming`([unapply(int(t^2*exp(beta*s1)*exp(-(gamma0*t+(1/2)*gamma1*t^2
                              +(1/3)*gamma2*t^3)*exp(beta*s1))
                              /(gamma2*t^2+gamma1*t+gamma0), t = N .. M), N, M)],
                 [N > 0, M > 0]):
B2 := unapply(Int((a+t-tau1)^2*exp(beta*s2)*exp(-(gamma0*(a+t-tau1)
                  +(1/2)*gamma1*(a+t-tau1)^2
                  +(1/3)*gamma2*(a+t-tau1)^3)*exp(beta*s2))
                  /(gamma0+gamma1*(a+t-tau1)+gamma2*(a+t-tau1)^2), t = N .. M), N, M):
B3 := unapply(Int((b+t-tau2)^2*exp(beta*s3)*exp(-(gamma0*(b+t-tau2)
                  +(1/2)*gamma1*(b+t-tau2)^2
                  +(1/3)*gamma2*(b+t-tau2)^3)*exp(beta*s3))
                  /(gamma0+gamma1*(b+t-tau2)+gamma2*(b+t-tau2)^2), t = N .. M), N, M):
F0 := A1(0, tau1)+A2(tau1, tau2)+A3(tau2, c):
F1 := B1(0, tau1)+B2(tau1, tau2)+B3(tau2, c):
Digits:=30:
CodeTools:-Usage( NLPSolve(1/(n^3*(F1*(F0-1))),
                           tau1 = 115 .. 201, tau2 = 237 .. 273, t2 = 145 .. 250,
                           variables=[tau1,tau2,t2]) );

memory used=1.72GiB, alloc change=56.00MiB, cpu time=17.41s, real time=17.05s

[                                   -8   
[-3.25820833082507756883676501482 10  , [

  tau1 = 176.979321680058026542850435500, 

  tau2 = 273.000000000000000000000000000, t2 = 145.000000000000000000000000000

   ]
  ]]

Hmm. If a name is constructed using Delta and epsilon from the greek letter palette (so as to get it nicely typeset as input, say) then the underlying construct is `Δε` as a name.

Under "standard" typesetting level the function call `Δε`(T, z) gets its output displayed as an infix call. But under "extended" typesetting that does not happen. The same goes for, say, `&g;&h;`(T, z) even though those are not known entities, I think.

Under either typesetting level the function call `Δ`(T, z) is displayed as an infix call, I believe.

I've submitted all this as an SCR.

If one enters the name using the greek letter palette, in 2D Math input mode, then right-click context menu action can convert to an Atomic Identifier, which I believe becomes `#mi("Δε")` and function calls with that name do not display as infix calls. So that may be another way to do it.

@JAnd I suspect that both of those things are possible.  I don't have the time to try it right away (and someone else might accomplish it in the meantime).

What version of Maple are you using, by the way?

Are you asking for a shaded relief map in 2)? Are the values used previously for the shading scheme also the altitudes, and if so what is the scale (units) of the data?

Do you separately want 1) as a relief map (shaded how?) with a transparent, constant-height, contour map (as in earlier response) lying above it?

This is an exciting Question.

@JAnd Maple's plot data structures can be examined. That, and experiment, and reading on forums like this about what other people have done, has augmented my understanding.

There are some kinds of useful plot which the stock plotting commands don't produce directly, but which can nevertheless be constructed programmaticaly using customized code or procedures.

For example, in the past I have posted on this site (here, here, here, and here) about some kinds of customized 3D and 2D plot shading, including achieving what is sometimes called texture maps on surfaces. As of Maple 18 some of that kind of thing (see here) can be accomplished directly using stock commands.

The documentation on the plot data structures is one place to look. Examination of the structure of actual plot output -- by example -- is another.

@Carl Love I think that I knew this was undocumented, and forgot to mention it, sorry. Over the years, more and more plot stuff has been allowing float[8] rtables both for the value data and the color data -- it's evolving for the better. Lots of functionality and documentation improvements have been made, but there's more to do I think.

In this case, I think that any float[8] rtable ideally ought be allowed for the COLOR substructure as long as the number of entries was right (a match to the GRID/MESH entry number in the HUE case, and 3 times the GRID/MESH entry number in the RGB/HSV vase). Ie, it would be better if any of Vector/Matrix/Array were allowed as long as the entry number was ok (since it;s all contiguous in memory anyway...

@Carl Love It is not necessary to convert the COLOR data to the (larger in memory) listlist structure. An Array will do (and it already is datatype=float[8] by the import).

By using ranges in the list argument to ArrayTools:-Alias (or ArrayTools:-Reshape) one can obtain an Array rather than a Matrix. Actually, a 1D Array could also serve here.

Download sphrdat.mw

@fhqtmso Yes, I understood what you wanted, I think. You want an unevaluated function call with arguments like T,z and the name of the operator should be the conjoining of capital greek Delta and lowercase greek epsilon (all nicely typeset).

I believe the problem is that Maple uses & (ampersand) in two special ways for typesetting. The older use is that a name beginng with ampersand typesets as an infix operator. This can be useful. The more recent mechanism that uses ampersand in a special way is that the underlying plaintext code representation of specially typeset names (including conjoined greek letters) are names with ampersand as first character. An unevaluated function call with a function name such as yours hits the unfortunate intersection of these two uses. 

If you just needed that call as if it were an expression tthen you could put name (single left-) quotes around the whole thing, including the (T,z) bit. But then that bracketed bit might display in italics. I don't have Maple at hand, to test. Perhaps someone could test, or think of another workaround.

@nm It's possible to imagine someone trying to create a name of so-called atomic identifiers (in undocumented TypeMK), and then finding that the 2D math output getting getting rendered as an infix call (even if lprint might reveal the structure to stop be just an unevaluated functions n call).

So, not so ridiculous on the part of the user, if it's a result of 1D/2D input awkwardness and documentation confusion.

Perhaps the OP could explain what is really wanted, in terms of the function name, font style (italic/Roman?), etc.

@nm There is no need for the `=` in the call to assign. The usual and robust way to use it in your example would be more like,

  assign( 'result' , dsolve(...) )

In that way you would not have to unassign `result`. In your previous version , on the repeated call, `assign` was being passed something other than a name as the (lhs of an equation as) first argument (normal evaluation rules).

@Mac Dude .mla can store a whole module, but in general .m cannot.

So yes indeed a module should be stored in a .mla file instead of a .m file.

The savelib command is not deprecated.

(In my not so humble opinion the save command should have been changed, so as to write out to .mla rather that .m and thus be able to handle modules etc, in Maple 6 or 7. Oh well.)

It seems that both `plot` and `Optimization` suffer because by default they both may attempt to evaluate under `evalhf` and be restricted to values (+/-) in the ranges of about 1e-307 to 1e308.

For plotting this is fixed by scaling (...and reminds me a bit of this).

For Optimization:-Maximize (NLPSolve) it suffices to prevent evalhf and bump up working precision Digits just a little. The `type` check in `H` below helps bypass evalhf-mode evaluations of the objective. The scaling of the objective is not necessary here.

By setting UseHardwareFloats to false I can get a result accurate to a handful of digits just by increasing Digits to about 12 or 13 (which normally would still allow hardware precision objective evaluations via evalhf, if UseHardwareFloats had its default value of `deduced`). But below I use Digits=30, regardless.

In short, very high working precision is not necessary to solve the problem, though it may be one easy way to force it.

restart:

f := (a, b, k) -> (Sum(exp(-x)*x^m/(m!), m = a .. b))^k:

h := f(0,0,82)*f(1,3,49)*f(4,6,47)*f(7,10,47)*f(11,15,57)*f(16,20,40)
     *f(21,25,38)*f(26,35,52)*(1-f(0,35,1))^91:

H:=proc(X)
     if not type(X,numeric) then
       return 'procname'(args);
     end if;
     evalf(subs(x=X,h)):
end proc:

Digits:=30:
UseHardwareFloats:=false:

Optimization:-Maximize(H(x),x=0..20)[2];

                    [x = 15.6881165580848572618920824132]

#plot(10^(1550)*H(x), x=0..20);