@Markiyan Hirnyk You forgot to restart between the two cases, so in your worksheet some computations are remembered and your second call is artifically appearing faster than it is.

Also, it's a mistake to re-execute with !!! rather than line by line, and to display the plots. On avg the second example is slightly faster (about 109ms versus 125 ms on my machine, over many separate runs). This difference might be due to the fact that the `map` case has an extra custom operator call ( as i->i*sin(i) ) for each entry's construction. And the `map` case produces two lists (one of which is temp garbage) rather than just one, so there is a memory used and alloc difference as well. But these effects might become negligible as the examples becomes much larger and involved.

restart;
with(CodeTools):
Usage(plot(map(i->i*sin(t),
           [seq(i, i = .1 .. 1, 0.2e-2)]), t = -2*Pi .. 2*Pi)):
memory used=131.28MiB, alloc change=41.86MiB, cpu time=1.90s, real time=2.09s, gc time=46.80ms

restart;
with(CodeTools):
Usage(plot([seq(i*sin(t), i = .1 .. 1, 0.2e-2)], t = -2*Pi .. 2*Pi)):
memory used=131.58MiB, alloc change=41.12MiB, cpu time=1.89s, real time=2.10s, gc time=46.80ms

The small size of the example makes the variation relatively huge, between runs. So without a larger run, or averaging, it's too easy to get an erroneous conclusion.

@Markiyan Hirnyk I ran your worksheet in Maple 18.01 and it displayed z not z~ as output.

@Preben Alsholm I wonder whether this kind of output -- or something similar -- might relate to why inttrans is still table-based. Perhaps there are recursion or efficiency issues. I'm just wondering out loud -- I don't know.

@Markiyan Hirnyk You cite only the first portion of a sentence, out of context. The whole sentence qualifies why loading is not wanted.

The full sentence by the OP was, "I do not like to load a package using with() and then use its commands and functions, since I then lose track knowing from which package a function or command being used in the code came from when I look at the code later on." So my suggestion to retain the explicit long indexed form in the input function call does directly address the stated need in the latter clause. The last sentence also links the desire to avoid package loading with retention of the fully qualified name, ie, "I really do not like loading packages as I said, and like to keep the name of the package attached to each function to help me know where each function is coming from."

Anyway, it does work for me,

restart;
with(inttrans,laplace):
f:=t->piecewise(t<0,0,t>=0 and t<z,t,t>z,z):
r:=convert(f(t),Heaviside):
r:=inttrans[laplace](r,t,s);

                                                                                 z
    r := laplace(t Heaviside(z - t), t, s) - z laplace(Heaviside(z - t), t, s) + -
                                                                                 s
eval(r,z=0.5);

            0.5000000000 (2. - 1. exp(-0.5000000000 s) (s + 2.))
            ----------------------------------------------------
                                     2.                         
                                    s                           

                                                   1.      
                 0.5 (1. - 1. exp(-0.5000000000 s))     0.5
               - ------------------------------------ + ---
                                  1.                     s 
                                 s                         

kernelopts(version);

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

@nm One difference is that the enclosure of the plots within a GUI Table affects the stretching differently w.r.t the vertical and horizontal directions. This is partially why I referenced my response to your earlier Question, since that mentioned some properties of the Table.

The help-page plot,options also describes the size=[w,h] option. It mentions an exception for w in the case of a plot array (which is what BodePlot returns).

I would say that the whole 2D plot aspect ratio business is much easier and sensible outside of a GUI Table (especially one with default re-sizing properties). I have been investigating a command that acts much like plots:-display(Array(...)) but offers up-front programmatic control over all the GUI Table properties - I'll try and add a note here if I find time to polish it up and post for feedback.

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