I'm not sure why maplemint is still a Library routine, when it is not kept as up-to-date as the standalone executable `mint` and also does not have as many options.

Perhaps the maplemint command should be changed, to simply call out to mint. Here's a really crude Linux-specific version of that, just to illustrate.

> mint := proc(f,extras::string:="")
> local fname,oldiface;
>   fname := "/tmp/foo";
>   oldiface := interface('verboseproc');
>   interface('verboseproc'=3);
>   writeto(fname);
>   printf("%a := ", f);
>   print(f);
>   printf(":\n");
>   writeto(terminal):
>   fclose(fname);
>   interface('verboseproc'=oldiface);
>   system(cat("/usr/local/maple/maple12.01/bin/mint ",extras," ",fname));
>   NULL;
> end proc:
>
> mint(`convert/CompSeq`);
    |\^/|      Maple 12 Diagnostic Program
._|\|   |/|_.  Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2007
 \  MINT   /   All rights reserved. Maple is a trademark of
 <____ ____>   Waterloo Maple Inc.
      |
Procedure convert/CompSeq( e1 ) on lines 1 to 77
  These local variables were used but never assigned a value:  result
>
> mint(`convert/CompSeq`,"-i 3");
    |\^/|      Maple 12 Diagnostic Program
._|\|   |/|_.  Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2007
 \  MINT   /   All rights reserved. Maple is a trademark of
 <____ ____>   Waterloo Maple Inc.
      |
Nested Anonymous Procedure proc( s ) on lines 44 to 56
  There are 2 equations used as statements on lines 50, 54
  Global names usage:  `&:=`, `&function`
Procedure convert/CompSeq( e1 ) on lines 1 to 77
  These local variables were used but never assigned a value:  result
  Global names usage:  `&%`, `&%%`, `&%%%`, `&ERROR`, `&RETURN`, `&args`,
      `&break`, `&done`, `&expseq`, `&for`, `&function`, `&hashtab`, `&if`,
      `&local`, `&next`, `&proc`, `&quit`, `&read`, `&save`, `&series`,
      `&statseq`, `&stop`, CompSeq, globals, locals, params, `||enate`
Global names used in this file:  `convert/CompSeq`

There are many ways to improve the above, naturally. The call to `system` could be replaced by an appropriate `ssystem` call, so that the ascii description at the top of mint's output could be removed. And it could be platform independent, etc, etc.

acer

Yes, I see what you mean.

I suppose that I am just not a fan of such side-effects on argument names, in cases where the task can be programmed by other more straightforward means.

For example, without using lists, it seems to me as if this example can be done most simply by using multiple assignments,

> f := proc(x,y) x+1,y+1; end proc:

> a,b := f(a,b);
Error, recursive assignment

> x,y := 10,20:
> x,y := f(x,y):
> x,y;
                                    11, 21

I realize that the OP and learned responders here would think of that easily, and that it's nothing special. To me, it seems the best way to go. When programming from the top-level, there is some additional protection against recursive assignment. But even more importantly, the straightforwardness makes it harder for the non-expert to get in a muddle.

acer

Yes, I see what you mean.

I suppose that I am just not a fan of such side-effects on argument names, in cases where the task can be programmed by other more straightforward means.

For example, without using lists, it seems to me as if this example can be done most simply by using multiple assignments,

> f := proc(x,y) x+1,y+1; end proc:

> a,b := f(a,b);
Error, recursive assignment

> x,y := 10,20:
> x,y := f(x,y):
> x,y;
                                    11, 21

I realize that the OP and learned responders here would think of that easily, and that it's nothing special. To me, it seems the best way to go. When programming from the top-level, there is some additional protection against recursive assignment. But even more importantly, the straightforwardness makes it harder for the non-expert to get in a muddle.

acer

I'm not sure how try..catch would help in those two particular routines. But, perhaps you meant more generally, and in which case I'd agree.

Calls to those two routines complete OK, even when x and y have not yet been assigned. But does not subsequent accessing of either x or y throw maple into an endless recursion?

acer

I'm not sure how try..catch would help in those two particular routines. But, perhaps you meant more generally, and in which case I'd agree.

Calls to those two routines complete OK, even when x and y have not yet been assigned. But does not subsequent accessing of either x or y throw maple into an endless recursion?

acer

One can observe what happens if `inc` (or Robert's `test2`) are called in the case that x and y have not yet been assigned with values.

It's not that those solutions are badly implemented. It's more that the goal is suspect.

There's always added risk of coding up a recursive assignment inside a procedure. But this request seems almost to go looking for a bit of trouble.

acer

One can observe what happens if `inc` (or Robert's `test2`) are called in the case that x and y have not yet been assigned with values.

It's not that those solutions are badly implemented. It's more that the goal is suspect.

There's always added risk of coding up a recursive assignment inside a procedure. But this request seems almost to go looking for a bit of trouble.

acer

See the ?LinearAlgebra,GenerateMatrix help-page.

acer

See the ?LinearAlgebra,GenerateMatrix help-page.

acer

What course is it for? What boundaries can you describe for the scope of the project.

I can't tell yet whether you want suggestions for topics (1st yr Calculus, or 4th yr degree project?) or suggestions on how to use or learn to use Maple.

acer

Command completion (on Linux, ctl-shift-space) does seem to work inside Math Containers.

For getting the value of a Math Container,  DocumentTools:-GetProperty seems to work. But what it produces isn't necessarily digestible by MathML:-ImportModified, if the content is some particular forms of 2D Math.

It might be interesting to know exactly what subset of 2D Math in a Math Container can be handled by ImportModified.

acer

Command completion (on Linux, ctl-shift-space) does seem to work inside Math Containers.

For getting the value of a Math Container,  DocumentTools:-GetProperty seems to work. But what it produces isn't necessarily digestible by MathML:-ImportModified, if the content is some particular forms of 2D Math.

It might be interesting to know exactly what subset of 2D Math in a Math Container can be handled by ImportModified.

acer

1) I was suggesting that perhaps there was a bug in how Maple itself was collecting garbage produced during "eval" callbacks. I am not sure whether this is the case or not. But it would not be your bug.

2) In the original code, the objective would not run under evalhf due to the `int` call. But operator form can indeed run under evalhf mode. For example,

> restart:
> infolevel[GlobalOptimization]:=2:

> Data := matrix(1,1,[1]):

> G := proc(x) x^2*Data[1,1]; end proc:

> GlobalOptimization:-GlobalSolve(G,-1..1);
GlobalSolve:   calling NLP solver
SolveGeneral:   calling global optimization solver
SolveGeneral:   number of problem variables   1
SolveGeneral:   number of nonlinear inequality constraints   0
SolveGeneral:   number of nonlinear equality constraints   0
SolveGeneral:   trying evalhf mode
SolveGeneral:   total number of function evaluations   1035
SolveGeneral:   runtime in external solver   0.
SolveGeneral:   maximum constraint infeasibility   0.
                                  [0., [0.]]

Note the message about "trying evalhf mode above". Notice also this following behaviour,

> evalhf(G(2.0));
                                      4.
> H := proc(x)
>   x * int(sin(t),t=0..1);
> end proc:
> evalf( H(2.0) );
                                  0.919395388

> evalhf( H(2.0) );
Error, unable to evaluate function `int` in evalhf

3) I have to correct myself slightly, about `data`. In your original example, it's not a barrier to evalhf. But if one encapsulated the example above within a procedure, then it would be. For example,

> restart:
> infolevel[GlobalOptimization]:=2:

> f := proc()
>   local Data, G;
>   Data := matrix(1,1,[1]);
>   G := proc(x) x^2*Data[1,1]; end proc;
>   GlobalOptimization:-GlobalSolve(G,-1..1);
> end proc:

> f();
GlobalSolve:   calling NLP solver
SolveGeneral:   calling global optimization solver
SolveGeneral:   number of problem variables   1
SolveGeneral:   number of nonlinear inequality constraints   0
SolveGeneral:   number of nonlinear equality constraints   0
SolveGeneral:   trying evalhf mode
SolveGeneral:   trying evalf mode
SolveGeneral:   total number of function evaluations   1035
SolveGeneral:   runtime in external solver   0.
SolveGeneral:   maximum constraint infeasibility   0.
                                  [0., [0.]]

Notice how, in the above example, there is also a message, "trying evalf mode". The evalhf callback failed. And so would this,

> restart:

> f := proc()
>   local Data, G;
>   Data := matrix(1,1,[1]);
>   G := proc(x) x^2*Data[1,1]; end proc;
>   evalhf(G(2.0));
> end proc:

> f();
Error, (in f) lexical scoping is not supported in evalhf

You can check whether your procedure evaluates under evalhf, say by calling it on a sample point within an evalhf() call like I've done above. It can get a little tricky though. The Optimization or GlobalOptimization solvers may switch modes altogether if they encounter just one evaluation point which fails under evalhf. So success at just a single test point wouldn't assure that the solver only uses evalhf mode.

> G := proc(x)
>   if x<5 then
>     sin(x);
>   else
>     x * int(cos(t),t=Pi..x);
>   end if;
> end proc:
> evalhf(G(4.0)); # ok so far, but...
                             -0.756802495307928202

> infolevel[Optimization]:=2:
> Optimization:-Minimize(G,1..7);
NLPSolve:   calling NLP solver
NLPSolve:   using method=quadratic
NLPSolve:   number of problem variables
NLPSolve:   trying evalhf mode
NLPSolve:   trying evalf mode
attemptsolution:   number of evaluations taken   42
attemptsolution:   final value of objective   -4.79462137048670024
                 [-4.79462137048670024, [5.00000000615824103]]

> evalhf(G(7.0));
Error, unable to evaluate function `int` in evalhf

acer

Isn't InverseSurvivalFunction(Y, p) the same as Quantile(Y, 1-p), at least for continuous distribution functions?

Quantile is sometimes known as the inverse cumulative distribution function (or icdf as it's called in Matlab).

I wonder what, if anything, are the "standard" names for these things.

acer

Isn't InverseSurvivalFunction(Y, p) the same as Quantile(Y, 1-p), at least for continuous distribution functions?

Quantile is sometimes known as the inverse cumulative distribution function (or icdf as it's called in Matlab).

I wonder what, if anything, are the "standard" names for these things.

acer