@mapleq2013 Carl's responses above are good advice. I would agree that assigning procedures (or operators) to names with the syntax (allowed in 2D Math) of,

source(t):=sin(0.1* t) 

is the wrong road to take.

I would also say that trying,

plot(f(t), a..b);

is just plain wrong here. For an operator/procedure f then (even if f(t) does return unevaluated for symbolic t) the thing f(t) is a function call. So that unfortunate and invalid plotting attempt is classic syntactic mismatch, halfway between the expression calling sequence and the operator calling sequence. It should instead be either plot(f(t), t=a..b) or plot(f, a..b).

As far as differentiating your resulting procedure f1 you have a few choices. Since f1 is a procedure you can use the functional differentiation D(f1). Of course you won't get an exact symbolic formula from that, because f1 is purely numeric and there is no symbolic formula around to differentiate. But you can get Maple to do numeric differentation at a numeric input point, eg. evalf(D(f1)(4)) which will internally compute using fdiff a numeric finite differencing mechanism. So you don't have to reinvent that particular wheel.

If you use the search tools for this site then you should be able to find several old threads about higher derivatives and integrals of the solution procedures coming out of dsolve/numeric. In essence, apart from using evalf(Int(...)) or evalf(D(..)(..)) you can augment your original DE system with extra dependent variables and/or higher derivative terms. The leads to dsolve/numeric returning extra procedures which compute just what you want. Of course the numeric solving depends on the solving of the other dependent variables/quantities, sure.

In a somewhat related way, you can also use dsolve/numeric and its events options rather than do rootfinding with, say fsolve in order to compute the particular numeric value of independent variable t so as to match some specific value. This is a bit more effort to set up.

@eclark 

I think that it would be useful if Style sheets could also handle (save & re-use) the Markers shown in View->Show/Hide Contents drop-menu, as well as custom Header and Footer details.

@Carl Love member is a static export of a Group object G, which gets used instead of :-member when one calls member(g,G), etc.

with(GroupTheory):

G:=DihedralGroup(20);

                                 G := D[20]
exports(G,static);

     Degree, Supergroup, Labels, IsFinite, PermutationRepresentation, IsRegular, 
     numelems, Subgroup, Operations, member, `in`, GroupModule, HasProperty, 
     GetProperty, SetProperty

G:-member;

                   PermutationGroupImplementation:-member

eval(G:-member);

     proc(expr, self)
     local pg;
       if expr = [] then
         undefined
       elif type(expr, {'Perm', 'permlist'}) then
         thisproc(convert(expr, 'disjcyc'), self)
       elif type(expr, 'list'('list'('posint'))) then
         pg := :-permgroup(:-Degree(self), 
         map(convert, {op}(:-Generators(self)), ':-disjcyc'));
         if :-group:-groupmember(expr, pg) then undefined else 0 end if;
       else
         0
       end if;
     end proc;

@Carl Love What about `equals` in the custom group definition?  (...as it was on math.stackexchange.com)

restart:

with(GroupTheory):

G:=DihedralGroup(20):

H:=Group({[[1,6,11,16],[2,7,12,17],[3,8,13,18],
           [4,9,14,19],[5,10,15,20]]}):

IsSubgroup(H,G);

                              true

FactorGroup:= proc(G::GroupTheory:-Group,
                   N::satisfies(N-> GroupTheory:-IsNormal(N,G)))
# Returns the group G/N.
uses GT= GroupTheory;
   GT:-CustomGroup(
      GT:-LeftCosets(N,G),
      multiply = ((g1,g2)->
                  GT:-LeftCoset(Representative(g1)
                                . Representative(g2), N)),
      inverse = (g->
                 GT:-LeftCoset(Representative(g)^(-1), N)),
      equals = ((g1,g2) ->
                member( Representative(g1)
                        . Representative(g2)^(-1), N))
                  )
end proc:

F := FactorGroup(G,H):

GroupOrder(F);

                               10

@misvanrooij You could convert each Vector to list, and then form a list of lists as Markiyan has shown.

But you could also create an m-by-3 Matrix, where each Vector forms a row. Ie, (using a part of Carl's code)

plots:-surfdata(`<|>`(v||(1..6), w||(1..3), x1, x2, y1)^%T,
                labels = ["L/h", "n", "kg/m"],axes=normal);

or,

plots:-surfdata(<v1|v2|v3|v4|v5|v6|w1|w2|w3|x1|x2|y1>^%T,
                labels = ["L/h", "n", "kg/m"],axes=normal);

(You may already know that you could supply style=patchnogrid as an additonal plot3d option.)

Have you tried it with HTTPS using the URL package of Maple 18?

acer

This might of interest (esp. if you like to watch your machine grind), even with limited scope.

acer

Are you sure about eq2?

acer

Alec's code appeared earlier in a worksheet by John Oprea (appeared in the Application Center in 2001, but may date from around 1996 and appears to have been created in MapleV R4). They both used a wrapping call to evalf when initializing local `c` in the scalar iterating procedure. Alec used plots[densityplot] (more attractive) while John used plot3d (faster).

And John's code is very close to that which appeared in the Maple V -- Programming Guide (p.231 of my 1996 edition). That manual's example used exponent 4 rather than 2, producing a kind of "Mandelbroid" if I may use the term. Alexander Walz cites [1, 2] John's revision as early as 1996.

One drawback to using hue is that its shading cycles back, with both lower and upper extremes shaded red. But with a high maximal iteration limit most inputs end up relatively near the extremes. So a lot of the plot is red, and it's difficult to distinguish visually which points escaped early and which did not escape at all.

The code variants mentioned use different accounting schemes for escape, in terms of initial and maximal attained iteration counts. I actually like a scheme where the count starts at 1 but for which unattained escape is recorded as value 0, since that information can be used to say mask out pixel intensity.

It's interesting to me that when using (plot3d or) plots[densityplot] and its restricttoranges=true option the purely real axis is more closely utilized if the grid has an odd number of points in the imaginary (y) direction. This effect can show more clearly if the maximal iteration limit is not high (30, say).

The output=layer1 option to Maple 18's Fractals:-EscapeTime:-Mandelbrot produces output where nonescape is recorded as value 0. This leads to a similar hue shading as where nonescape is recorded using the maximal iteration value (or 1 higher), because of the mentioned hue shading wrap-around with both extremes showing as red.

There is a mistake in that Library routine, where module local procedure Fractals:-EscapeTime:-sourceMandelbrot fails to check and record a possibly early escape at iteration 1. It starts checking at 2.

One thing that routine does have is additional easy checks against the input point being in either the largest or secondary bulbs of nonescaping points. So here is a density plot variant that does those checks and runs a bit faster for the interesting ranges like in the discussed code variants. I haven't tried to optimize the code's subexpressions, but for this code below on my machine the cross-over for speed is about 75 as the maximal iteration limit. More iterations than that and the easy checks pay off, while for fewer iterations their overhead is a penalty.

restart:

Mandelfun2 := proc(a, b, N)
local z1, z2, z1s, z2s, i, t, temp;
 z1 := a; z2 := b;
 z1s := z1^2; z2s := z2^2;
 if (z1+1.0)^2+z2s < .625e-1 then
    return N+1;
 end if;
 t := (z1-.25)^2+z2s;
 if (t+z1-.25)*t < .25*z2s then
    return N+1;
 end if;
 for i to N while z1s+z2s < 4 do
   temp := z1s - z2s + a;
   z2 := 2*z1*z2 + b; z1 := temp;
   z1s := z1^2; z2s := z2^2;
 end do;
 i;
end proc:

Mandelfun := proc(x,y,N)
local n,c,z;
     c:= x+I*y;
     z:= 0;
     for n to N while abs(z) < 2 do
          z:= z^2+c
     end do;
     n
end proc:

n := 250:

CodeTools:-Usage(
   plots:-densityplot(
        'Mandelfun2'(x,y,75), x=-2.0..0.7, y=-1.35..1.35, grid=[n,n+1],
        colorstyle= HUE, restricttoranges=true,
        axes= boxed, scaling= constrained, 
        style= patchnogrid,
        labels= [Re,Im]) ):
memory used=1.39MiB, alloc change=0 bytes, cpu time=499.00ms, real time=497.00ms, gc time=0ns

CodeTools:-Usage(
   plots:-densityplot(
        'Mandelfun'(x,y,75), x=-2.0..0.7, y=-1.35..1.35, grid=[n,n+1],
        colorstyle= HUE, restricttoranges=true,
        axes= boxed, scaling= constrained, 
        style= patchnogrid,
        labels= [Re,Im]) ):
memory used=1.02MiB, alloc change=0 bytes, cpu time=500.00ms, real time=499.00ms, gc time=0ns

In Maple 18 the revised plots:-surfdata command can be used to easily turn a single layer black & white image Array into a hue shaded density plot. Here's a simple procedure that calls the Fractals:-EscapeTime:-Mandelbrot command as then follows that up with such a conversion. The timings seemed to improve in subsequent runs in the same GUI session, even after restart.

restart:

# Initialize the Compiler and ModuleLoad,
# incurring a one-time hit after each restart which
# may reasonably be excluded from timing results
# if we expect to convert more than once.
with(Fractals:-EscapeTime):

MandelDens:=proc(N::posint,
                 cll::complex(numeric),
                 cur::complex(numeric),
                 {cutoff::posint:=4,
                  iterationlimit::posint:=100})
   local M;
   M := Fractals:-EscapeTime:-Mandelbrot(
          N, cll, cur,
          ':-cutoff'=cutoff,
          ':-iterationlimit'=iterationlimit,
          ':-output'=':-layer1');
   rtable_options(M,':-subtype'=Matrix);
   LinearAlgebra:-Transpose(M,':-inplace');
   rtable_options(M,':-subtype'=Array);
   plots:-surfdata(':-color'=':-COLOR'(':-HUE',M),
                   Re(cll)..Re(cur),Im(cll)..Im(cur),
                   ':-dimension'=2,
                   ':-style'=':-patchnogrid',
                   ':-scaling'=':-constrained',
                   ':-axes'=':-box', _rest);
end proc:

n := 251:

CodeTools:-Usage(
  MandelDens(n, -2.0-1.35*I, 0.7+1.35*I,
             iterationlimit=75, labels=[Re,Im]) ):
memory used=3.24MiB, alloc change=17.73MiB, cpu time=63.00ms, real time=30.00ms, gc time=0ns

A more general purpose image to densityplot conversion utility would be useful. It might handle HUE, HSV, or RGB shadings. I'm thinking of Classic GUI users who cannot use ImageTools:-Embed, and for whom densityplots behave better. And another utility for densityplot to image conversion would also be useful. There I'm thinking of Standard GUI users, where images may stress the interface less. Perhaps more on that later.

@Christopher2222 It does not work for me on Maple 18.01 with symbol=point on 64bit Maple on Windows 7 Pro (ATI Radeon HD 4300/4500).

Increasing the symbolsize or expanding the `view` does not remedy it.

But it works fine without explicitly specifying symbol=point in the command and so without the accompanying substructure in the PLOT structure (ie. default symbol as per GUI, and default symbolsize).

@Carl Love Could `curves,rest` be split out simply just with selectremove of that specfunc type (using a list as originally, not a Vector)?

@Carl Love I suspect that one of the key aspects is that you and I switched it from Re(Int(...)) to Int(Re(...)).

And that can be made faster (even still allowing adaptive plotting). The first version I gave took about 8 seconds. The one below takes under 2 seconds on my Maple 18 (Intel i7, 64bit Windows) even without relaxing the requested accuracy of the numeric integration.

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:=1/2:
dpdx:=evalf[15](radnormal(DDP[1])):

#dpp:=q->Int(unapply(Re(eval(dpdx,[K=-0.1,Q=q])),x),0..1,epsilon=1e-5):
dpp:=q->Int(unapply(Re(eval(dpdx,[K=-0.1,Q=q])),x),0..1):

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

And a little more can be shaved off by instead using the commented line above which imposes a laxer tolerance on the numeric integration, getting it down to about 1.5 seconds on my machine.

This works for me in both Maple 17.02 and 18.00.

restart:                                                 

M := 2: alpha := 1/2:                                    

U := sum(sum(binomial(n-1, i)*x^(n-i-alpha)*(-a*n)^i*c[n]
             *GAMMA(n-i+1)/GAMMA(n-i-alpha+1),           
             i = 0 .. n-1), n = ceil(alpha) .. M):       

radnormal(convert(U,elementary));                        

                                                        1/2
                        (6 a c[2] - 4 x c[2] - 3 c[1]) x
                   -2/3 -----------------------------------
                                         1/2
                                       Pi

@itsme This might produce the same edited version of Grid:-Map (in 17.02 or 18.01 perhaps) that you suggested, using anames('user').

HackGridMap :=
   FromInert(subsop([5,1,1,2,1]
             =subs(_Inert_LOCAL(1)=_Inert_LOCAL(7),
                   op([5,1],
                      ToInert(proc() local var;
                                var:={anames('user'),
                                      '`grid/mapcmd`'};
                              end proc))),
             ToInert(eval(Grid:-Map)))):