It may not always help. but it quite often comes up that there is some benefit to preventing `evalf/int` from poking too hard at the integrand as an expression. One way to get that is to make the integrand an operator rather than an expression.

I suppose you realize that this is a nasty looking integral. It is very small for most of x=0..1, and then up around the range 0.93..1 it becomes very large. Well, it becomes larger than fits within the range of double-precision. Hence it may be beneficial to prevent `evalf/int` from using `evalhf` and concluding that the answer is Float(infinity).

As mentioned, this kind of approach is not going to always work. Nothing will always work. However, for this particular example,

restart:

y := 1: z := 2 + x + y: s := 1/2:
m2 := 5325: m1 := 5279: mz := 106055/10:

igrand := 1/z^3 *(x + y + 2* x*y)* (1 + s^2/(2 *m2^2* z))
          *exp(-(m2^2*x + m1^2*y)/s^2 + (mz^2 *(x + y + 2 *x*y))/(2* s^2* z)):

evalf(Int(unapply(igrand,x), 0..1.0, digits=136, epsilon=1e-10)):
evalf(%);
                                           29230
                             8.629559550 10     

With regard to your broader question, you could try saving your partial results before problematic calls, if you know what they are.

acer

Your guess is right, the procedure normally sees only the evaluated argument and not the name (to which it was assigned) that is used in the call.

However, there are some other ways to go about it.

One way is to call the procedure with an invocation using unevaluation quotes on the arguments. This works easily without having the procedure's parameters be specified (by type, or in number). This has the benefit (if I understand your wish rightly) of not requiring knowledge of the number of arguments at the time the procedure is defined.

restart:

p:=proc()
  local x;
  for x in [_passed] do
    print(eval(x,1),eval(x));
  end do;
  NULL;
end proc:

A:=<<4>>:
B[1]:=<<7>>:

p( 'A', 'B[1]' );
                                   A, [4]
                                  B[1], [7]

Another couple of ways involve using the uneval or evaln modifiers of parameters of a procedure. Unfortunately those cannot be used directly with the seq modifier, so it's not simple to be able to pass a sequence of such (whose number is not known in advance of defining the procedure).

Using A and B[1] from above,

p2 := proc( y::uneval, w::uneval)
  local x;
  for x in [y,w] do
    print( eval(x,1), eval(x,2) );
  end do;
  NULL;
end proc:

p2( A, B[1] );
                                   A, [4]
                                  B[1], [7]

p3 := proc( y::evaln, w::evaln )
  local x;
  for x in [y,w] do
    print( eval(x,1), eval(x,2) );
  end do;
  NULL;
end proc:

p3( A, B[1] );
                                   A, [4]
                                  B[1], [7]

acer

Firstly, it is spelled with a capital J. It is Jacobian, not jacobian.

Secondly, make sure that you are not entering rsin(t) when you meant r*sin(t). otherwise you'll just get the single name rsin. The same goes for rcos.

Thirdly, it appears that you already have the name r assigned to something else (a failed call to RandomMatrix, without loading the LinearAlgebra package?). You can undo that using the unassign command, or by issuing the command r:='r'. Or don't make that assignment before your current example.

Fourthly, make sure that you have either loaded the package using the command with(VectorCalculus) or you are calling it by its long-form name. Eg,

VectorCalculus:-Jacobian([r*cos(t), r*sin(t), r^2*t], [r, t]);

                             [cos(t)    -r sin(t)]
                             [                   ]
                             [sin(t)    r cos(t) ]
                             [                   ]
                             [              2    ]
                             [2 r t        r     ]

acer

Which java runtime do you have? It's possible to have multiple java runtimes even on OSX, I believe. If it is java 7 then could you try adding the JRE 1.6 (required for Maple 18) runtime obtained from Apple (legacy Java SE 6?)?

If you already have that java version then sorry, I don't have another suggestion.

acer

Your preamble loads the Physics package, etc, which rebinds `.`.

Those invocations of `.` result in z1 being a Physics:-`*` function call (in stock Maple 18.01).

restart:

with(Physics):
Physics:-Setup(mathematicalnotation = true): 
Physics:-Setup(anticommutativeprefix = psi):
ap1 := Physics:-Creation(psi, 1, notation = explicit):
am1 := Physics:-Annihilation(psi, 1, notation = explicit): 
ap2 := Physics:-Creation(psi, 2, notation = explicit):
am2 := Physics:-Annihilation(psi, 2, notation = explicit):

z1 := ap1 . am1 . ap2:

type(z1, specfunc(anything, Physics:-`*`));

                              true

acer

Why not substitute before writing to the file?

f := x-> arcsin(x):

str := StringTools:-Substitute(sprintf("%a",f(1)),"Pi","pi"):

str;
                            "1/2*pi"

file := cat(kernelopts(homedir),"/Documents/foo.txt"):

fopen(file,WRITE,TEXT):

fprintf(file,"%s",str):

fclose(file):

acer

It ought to be able to do that. See the Student[NumericalAnalysis][LinearSolve] command.

acer

For this example the result T below of a simple call to `solve` produces results which involve inequalities of only rational polynomials. And those are accepted by solve(...,x,parametric).

ee := 1/x < abs((x+4)/(x*a+2)):

T := [ solve(ee) ];

map(simplify,map(solve,T,x,parametric))[];

The last result is a sequence of separate solutions, which might be considered together.

Stitching all the solutions back together after appropriate re-interpretation (Or, And, NULL, or what have you) , and simplifying, might be an irksome amount of bookkeeping. I don't know whether it's reasonable to attempt using `solve` to do that too.

In other words it seems as if your example is one which solve,parametric can be used to handle manually (even though it's not in the class which solve,parametric accepts outright). 

acer

Your scheme works for me if the semicolons are escaped in the strings. Ie, the data file having as its first line,

c "a:=1\;" -c "b:=2\;" -c "c:=3\;"

You could also use Maple's ability to do multiple assignment in a single statement, ie,

-c "a,b,c:=1,2,3\;"

If you want to get fancier with scripting (on a unix-like system such as Linux, say), you could look at this old thread.

acer

applyrule( n::posint*F(K,L) = F(n*K,n*L), 2*F(K,L) );

                          F(2 K, 2 L)

Your original will match in the first of the following cases (but apparently you want it to match according to a specific typed pattern).

Observe the differences,

applyrule( n*F(K,L) = F(n*K,n*L), n*F(K,L) );

                          F(n K, n L)

applyrule( n*F(K,L) = F(n*K,n*L), p*F(K,L) );

                           p F(K, L)

applyrule( n::name*F(K,L) = F(n*K,n*L), p*F(K,L) );

                          F(p K, p L)

acer

You could define your own numeric event handler, to trap this situation and then (internal to that handler procedure) it could set a global flag which let you know that something specific happened.

A numeric event may not always be trapped with try...catch.

acer

A symmatric `table` has this property. A nice flexibilty of a `table` is that you don't need to set explicit finite limits on the bounds, up front. And it can be indexed by non-numeric symbolic index values.

T:=table([],symmetric):
T[i,j,k,l], T[j,k,i,l];

                        T[i, j, k, l], T[i, j, k, l]

T[2,3,1,U] := 4:

T[3,1,U,2];

                                      4

For a (two dimensional) Matrix, there is the `shape=symmetric` option, which gives the same effect but needs explicit finite bounds for the indices which begin at 1 (one).

For higher dimension Arrays it is not difficult to write a custon indexing-function with the same properties. (I saw someone do it once, forget who... If you want I could recreate it.) This too would be for explicit finite index bounds.

acer

Under Maple's usual evaluation rules, what the outer sum sees as its first argument when you call your T(x,3) is this,

sum(binomial(3,k+p),k=1..3-p)*x^p;

                               0

Instead, you can delay the evaluation of the inner sum (until index of summation `p` gets an actual value) with unevaluation quotes. Or you can use `add` which has special evalution rules.

T:=(x,m)->add( add(binomial(m,k+p),k=1..m-p)*x^p,p=0..m-1):
T(x, 3);
                           2          
                          x  + 4 x + 7

T:=(x,m)->sum( 'sum'(binomial(m,k+p),k=1..m-p)*x^p,p=0..m-1):
T(x, 3);
                           2          
                          x  + 4 x + 7

T:=(x,m)->sum( 'sum(binomial(m,k+p),k=1..m-p)'*x^p,p=0..m-1):
T(x, 3);
                           2          
                          x  + 4 x + 7

This is a FAQ.

acer

I suppose that for you it is key that you can programmatically determine the situation after calling `solve`. So Warning and userinfo messages are not of direct use there.

But in the case of the "solutions may have been lost" warning an assignment is made to the name _SolutionsMayBeLost, and you can test for that.

restart:

P := proc()
  local ans;
  # First, clear the flag.
  :-_SolutionsMayBeLost := ':-_SolutionsMayBeLost';
  ans := solve(args);
  if ans=NULL then
    if _SolutionsMayBeLost=true then
      return FAIL; # indeterminate case
    else
      return false; # `solve` thinks no solution exists
    end if;
  else
    return ans;
  end if;
end proc:

P( {y-x=0,y-x=1} );

                             false

P( {a+r*t*ln(l)+(1-l)^2*m-b-r*t*ln(s)-(1-s)^2*n = 0,
    a+r*t*ln(1-l)+l^2*m-b-r*t*ln(1-s)-s^2*n = 0},
   {l, s} );

                              FAIL

This kind of thing (possibly tweaked), is my best guess at what will serve your need here.

Opinions welcome, whether it makes any sense to try to save the inbound value of _SolutionsMayBeLost, do the work inside a try..catch, and then restore that value in a `finally` clause.

acer

For starters, you will need a semicolon statement terminator on the line preceding the while. In both 1D and 2D input modes it is invalid without that.

Next, the error message along with this code are a hint that you are using 2D Math input. The 2D Math input parser is picky. If I added semicolon terminators to all the lines immediately preceding end if statements, and if I also ensured that there was at least one space between any if and the round bracket your code immediately follows with (as separator), then I could execute the code without any parsing error in both Maple 17.01 and 18.01.

acer