How about beta=0 ?

More seriously, perhaps, what kind of answer are you hoping for? An exact characterization of all roots? Or a floating-point approximation to all roots within a finite range? Or...?

acer

I'm not really sure what it is that you are asking.

Is it something like this, perhaps?

acer

@mattcanderson1 This is a silly response since it includes basic math (not what was asked) but provides no real answer to the questioner's difficulty with Maple usage.

@Carl Love The procedure `isconvex` is a machine for finding bugs and weaknesses in `is`.

@Markiyan Hirnyk If you tried to paste the 1D Maple Notation code from my reply above (without the leading prompt symbols) as 2D Maple input then the GUI will issue an error. It is 1D code, and plaintext 1D notation Maple code cannot generally be pasted as straight plaintext into a 2D Math input area.

In Maple 18.01 the 1D Maple Notation code pasted easily and successfully into an execution group.

But the code posted above is not prepared for more than one unknown, and blindly picks off the first. But you have another post with an example with one unknown variable and 2 constrained parameters. So here is an edited version which accepts an extra argument (name).

Please note that this is 1D Maple Notation code, I remove the leading command prompts.

restart:
isconvex := proc(expr,x::name,A::realcons:=-infinity,B::realcons:=infinity)
 local a,b,t,use_expr,res;
   #x := indets(expr,name) minus {constants};
   if nops(x) = 1 then
     x := op(x);
   else error;
   end if;
   # For more than one variable, one could test
   # positive-definiteness of the Hessian.
   res := is( diff(expr,x,x) >=0 )
            assuming x>=A, x<=B;
   if res<>FAIL then
     return res;
   else
     userinfo(1,'isconvex',`falling back to the definition`);
     # Is it better to expand, or simplify, or put
     # Normalizer calls around the two-arg evals or
     # their difference, oder...?
     use_expr:=expand(expr);
     is( eval(use_expr,x=(1-t)*a+t*b) <=
         (1-t)*eval(use_expr,x=a)+t*eval(use_expr,x=b) )
       assuming a<=b, t>=0, t<=1, b<=B, a>=A;
   #else
   ##Is global optimization another fallback?
   end if;
 end proc:

f := log[x](1+(x^a-1)*(x^b-1)/(x-1)):

isconvex(f, x, 0, 1) assuming a>0, a<1, b>0, b<1;

                              FAIL

isconvex(f, x, 1, infinity) assuming a>0, a<1, b>0, b<1;

                              FAIL

isconvex(eval(f,[a=1/2,b=3/4]), x, 0, 1);

# Maple ran out of memory on me, for the last one above, and never got past
# the initial 2nd deriv test. I also got a FAIL for it, with just the
# "definition" fallback. One could try with simplify or expand at judicious points.
# Analysis is hard in a CAS, and `is` could be improved.

I'll let you know if I get any results under simplify or expand of intermediate expressions (using either method of the code above).

One approach might be to first hit your original procedure `unapp` with codegen[prep2trans] in order to generate a Maple procedure with conditional code rather than piecewise constructs.

This worked for most but not all of the terms. I was not yet able to succeed like this, as it seems to go wrong generating conditional code while handling the rhs terms which involve sums of terms involving piecewise.

It might be easier to have Maple generate the entire float[8] Matrix of results (for all timesteps), which I believe I might have suggested in a comment buried in your ealier post.

If instead you decide to stick with your original approach from the earlier post then at the very least I would suggest that you first evaluate the list (or Vector) [BAT_A, BAT_V,...] at elimsol[1] prior to using unapply. That way each call to your unapp procedure will generate a list (or Vector) of numeric values directly. That at least should perform better than the original way which produced a list of equations [BAT_A=..,BAT_V-.,...] at each timestep (and for each of which the a seperate evaluation or lhs map was needed to pick off the numeric values). Hope that makes sense.

acer

Did you intend the first instance of rho on your (red code) input line to be followed by a multiplication symbol?

acer

@taro If you got 1/2 as that last result then your procedure generated by shift(sin) is behaving like sin(x+1). So maybe the problem you see is just with printing.

By the way, in a console, using the commandline (TTY) interface, I see,

%maple9 -s
    |\^/|     Maple 9 (APPLE PPC OSX)
._|\|   |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2003
 \  MAPLE  /  All rights reserved. Maple is a trademark of
 <____ ____>  Waterloo Maple Inc.
      |       Type ? for help.

shift:=(f::procedure)->(x->(f(x+1))):

shift(sin);

                                x -> sin(x + 1)

%(Pi/6-1);

                                      1/2

kernelopts(version);

             Maple 9.01, APPLE PPC OSX, Jul 9 2003 Build ID 137227

shift:=(f::procedure)->(x->(f(x+1))):

shift(sin);

                                x -> sin(x + 1)

kernelopts(version);

            Maple 9.03, IBM INTEL LINUX, Oct 1 2003 Build ID 141050

And, using Maple V R5 on a sparc,

shift:=(f::procedure)->(x->(f(x+1))):

shift(sin);                          

                                x -> sin(x + 1)

%(Pi/6-1);                           

                                      1/2

@teh_allchemist The command to query for curent memory allocation by the OS to the running kernel is kernelopts(bytesalloc) and not kernelopts(bytesused).

The former reports on allocated memory. The latter reports on how much was "processed" by the memory management system, and generally shows a much larger value that is not at all an indication of the current memory allocated. It sounds like you want the former, for your measurement.

Also, passing out a huge collection of lists to Matlab, and then invoking operations in Matlab to extract the numeric array values, line by line and entry by entry or even column by column, doesn't sound like an approach for any kind of decent performance.

Instead, why not convert the huge list of equations to a Matrix or Vector of just the numeric values, in Maple itself, and pass that to Matlab instead. You could even store it to a file. You could store a Vector of the column header names separately from the numeric data. You could store the purely float data in a Matrix or Vector in Maple with datatype=float[8] as itsme suggested. You could export that to text file, or even to a Matlab format binary format file. I would be surprised if this couldn't all be done very efficiently.

I suggest processing the symbolic equations in Maple, first, and then exporting the resulting compact numeric Matrix and a small Vector of just the column header names. That's what itsme's code does, I believe.

Even if you are sitting with control currently in Matlab and have produce the large symbolic list structure in a running (associated) Maple session, then it'd likely still be much better to make a single `maple` call-out, to convert the rhs's of the symbol equations to a Maple datatype=float[8]  Matrix in one fell swoop. Even if you had to make another `maple` call-out from Matlab to Maple, in order to get Maple to export that to a compact Matlab binary format file. 

Perhaps I don't properly understand which program you are running in to execute commands. It sounds to me as if you are running in Matlab, and calling out to Maple to run simulations and generate results (which you then want to import into your running Matlab). Is that near right?

@mapleq2013 The compile option translates the Maple code in the DE system to C, compiles that, and uses it for the many evaluations (think of the rhs driving terms in an explicit system, to get just the gist). All these stages are done internally, out of view.

There is a bit of overhead cost in such treatment (esp. the first invocation of the internal compiling mechanisms) but for non-small systems like yours the resulting faster evaluation code may bring a performance benefit that outweighs such overhead. 

@mapleq2013 I believe you'll find that the `parameters` options works in that uploaded sheet even without the `compile` option accompanying it. You may have either been using invalid syntax for the `parameters` option, or (by the sound of that emitted message) trying to implicly use a "parameter" by just having an unassigned name in the DE yet not explicitly specifying it with the `parameters` option.

To reiterate, the Standard Java GUI is a separate process from the running kernel. On Windows the kernel is `mserver.exe` and the GUI is `maple.exe` (or `maple.exe *32`) in the Task Manager. On Linux the kernel is `mserver` and the Standard GUI is just "java" as seen under the `top` task manager utility.

Using dsolve/numeric's `parameters option helps on your example with kernel memory and execution time. Switching that long single 2D Math expression for the DE system to 1D Maple Notation (red code) helped with the GUI responsiveness and memory use.

On Linux 64bit with Maple 18.00 and using your original Document I saw sluggish response while editing, and even crashed the GUI a few times while trying to edit the 2D Math. On my console I got repeated java messages about the jvm running out of heap space and its GC failing.

@Carl Love There are two processes consuming memory -- kernel (mserver) and GUI (java).

The kernel takes a few hundred MB, and that might be reduced by using the parameters[omega] option of dsolve/numeric. (I am not sure how easy it might be to also try and replace some of those piecewises with events...)

I am also seeing the GUI java process taking 550 MB or resident memory (on 64bit Linux). The resident memory goes up further if I Close and re-Open the Document in the same GUI session. It got sluggish just editing the 2D Math of the DE system. It may be that moving that to a Code Edit region could help there.

If the problem occurs even when you suppress all output then it might not be an issue with the interface.

How about uploading a worksheet that demonstrates the problem?

acer

@Andriy Another way to explain the difference is that for f:=k->k^2 the call f(k) will return an expression. In the case of f:=k->fsolve(x^2+k*x-1=0,x)[1] it so happens that f(k) generates an error. But in other examples f(k) could well return something unintended for unassigned symbolic argument k.

This is a FAQ. Since plot has Maple's usual evaluation rules the call plot(f(k),k=0..1) will evaluate its first argument f(k) and pass the result along to the plot procedure. In situations like you had, where f is not well prepared to handle an unassigned symbolic argument like k it is necessary to avoid this so-called premature evaluation.

One way to handle it is to delay the evaluation of f(k) as first argument to plot, as mentioned earlier.

plot( 'f'(k), k=0..1 );

# or plot( 'f(k)', k=0..1 ) if k is itself some function call you don't want evaluated

Another way is to use the operator form calling-sequence of plot, as mentioned earlier.

plot( f, 0..1 );

Yet another way is to construct f instead as a procedure which returns unevaluated for nonnumeric argument.

f := proc(k)
  if not type(k, numeric) then
    return 'procname'(args);
  end if;
  fsolve(x^2 + k*x = 0, x)[1];
end proc:

f(k);  # note f now returns unevaluated for nonnumeric argument

                                     f(k)

plot( f(k), k=0..1 );

This issue is not restricted to just plot. There is also an error guide page about it (keyed upon another common error message from such situations.

It is also possible to use unapply to turn an expression into a procedure that returns unevaluated for nonumeric argument(s). Eg,

f := unapply( 'fsolve(x^2 + k*x = 0, x)[1]', k, numeric ):

f(k);                                               
                                     f(k)

f(1.5);                                             
                                 -1.500000000

plot( f(k), k=0..1 );

It may be of interest to some that Mathematica users often encounter the issue. One can do a web search for Mathematica and NumericQ to get a feel for that.