Adding to the suggestions in the comments, I would use 'add' instead of 'sum', 'mul' instead of 'product', use an explicit `*` for all multiplications (instead of implicit multiplications or `.`), and use tau_||i for variable names instead of tau(i). All of these help minimize problems. Doing that, I get the equations

eqn1 := (mul(1-tau_||i, i = 1 .. 4)*delta*Delta*tau_||0)*(1+(1/16)*(add((16-j+1)/(g_0)*(j), j = 1 .. 16))+(1-mul(1-tau_||i, i = 1 .. 4)*delta*Delta)*(1+(1/16)*(add((16-j+1)/(g_0)*(j), j = 1 .. 16)))+(1-mul(1-tau_||i, i = 1 .. 4)*delta*Delta)^2*(1+(1/32)*(add((32-j+1)/(g_0)*(j), j = 1 .. 32)))+(1-mul(1-tau_||i, i = 1 .. 4)*delta*Delta)^3*(1+(1/32)*(add((32-j+1)/(g_0)*(j), j = 1 .. 32)))+(1-mul(1-tau_||i, i = 1 .. 4)*delta*Delta)^4*(1+(1/32)*(add((32-j+1)/(g_0)*(j), j = 1 .. 32))))/(1-(1-mul(1-tau_||i, i = 1 .. 4)*delta*Delta)^3) = 1;

eqn2 := (mul(1-tau_||i, i = 2 .. 4)*(1-tau_||0)*delta*Delta*tau_||1)*(1+(1/8)*(add((8-j+1)/(g_1)*(j), j = 1 .. 8))+(1-mul(1-tau_||i, i = 2 .. 4)*(1-tau_||0)*delta*Delta)*(1+(1/8)*(add((8-j+1)/(g_1)*(j), j = 1 .. 8)))+(1-mul(1-tau_||i, i = 2 .. 4)*(1-tau_||0)*delta*Delta)^2*(1+(1/16)*(add((16-j+1)/(g_1)*(j), j = 1 .. 16)))+(1-mul(1-tau_||i, i = 2 .. 4)*(1-tau_||0)*delta*Delta)^3*(1+(1/16)*(add((16-j+1)/(g_1)*(j), j = 1 .. 16)))+(1-mul(1-tau_||i, i = 2 .. 4)*(1-tau_||0)*delta*Delta)^4*(1+(1/16)*(add((16-j+1)/(g_1)*(j), j = 1 .. 16))))/(1-(1-mul(1-tau_||i, i = 2 .. 4)*(1-tau_||0)*delta*Delta)^3) = 1;

eqn3 := ((1-tau_||0)*(1-tau_||1)*(1-tau_||3)*(1-tau_||4)*delta*Delta*tau_||2)*(1+(1/4)*(add((8-j+1)/(g_2)*(j), j = 1 .. 4))+(1-(1-tau_||0)*(1-tau_||1)*(1-tau_||3)*(1-tau_||4)*delta*Delta)*(1+(1/4)*(add((4-j+1)/(g_2)*(j), j = 1 .. 4)))+(1-(1-tau_||0)*(1-tau_||1)*(1-tau_||3)*(1-tau_||4)*delta*Delta)^2*(1+(1/8)*(add((8-j+1)/(g_2)*(j), j = 1 .. 8)))+(1-(1-tau_||0)*(1-tau_||1)*(1-tau_||3)*(1-tau_||4)*delta*Delta)^3*(1+(1/8)*(add((8-j+1)/(g_2)*(j), j = 1 .. 8)))+(1-(1-tau_||0)*(1-tau_||1)*(1-tau_||3)*(1-tau_||4)*delta*Delta)^4*(1+(1/8)*(add((8-j+1)/(g_2)*(j), j = 1 .. 8))))/(1-(1-f_2*delta*Delta)^3) = 1;

eqn4 := ((1-tau_||0)*(1-tau_||1)*(1-tau_||2)*(1-tau_||4)*delta*Delta*tau_||3)*(1+(1/2)*(add((2-j+1)/(g_3)*(j), j = 1 .. 2))+(1-(1-tau_||0)*(1-tau_||1)*(1-tau_||2)*(1-tau_||4)*delta*Delta)*(1+(1/2)*(add((2-j+1)/(g_3)*(j), j = 1 .. 2)))+(1-(1-tau_||0)*(1-tau_||1)*(1-tau_||2)*(1-tau_||4)*delta*Delta)^2*(1+(1/4)*(add((4-j+1)/(g_3)*(j), j = 1 .. 4)))+(1-(1-tau_||0)*(1-tau_||1)*(1-tau_||2)*(1-tau_||4)*delta*Delta)^3*(1+(1/4)*(add((4-j+1)/(g_3)*(j), j = 1 .. 4)))+(1-(1-tau_||0)*(1-tau_||1)*(1-tau_||2)*(1-tau_||4)*delta*Delta)^4*(1+(1/8)*(add((8-j+1)/(g_3)*(j), j = 1 .. 8))))/(1-(1-(1-tau_||0)*(1-tau_||1)*(1-tau_||2)*(1-tau_||4)*delta*Delta)^3) = 1;

eqn5 := (f_4*delta*Delta*tau_||4)*(1+(1*1)*(add((1-j+1)/(g_4)*(j), j = 1 .. 1))+(1-f_4*delta*Delta)*(1+(1*1)*(add((1-j+1)/(g_4)*(j), j = 1 .. 1)))+(1-f_4*delta*Delta)^2*(1+(1/2)*(add((2-j+1)/(g_4)*(j), j = 1 .. 2)))+(1-f_4*delta*Delta)^3*(1+(1/2)*(add((2-j+1)/(g_4)*(j), j = 1 .. 2)))+(1-f_4*delta*Delta)^4*(1+(1/4)*(add((4-j+1)/(g_4)*(j), j = 1 .. 4))))/(1-(1-f_4*delta*Delta)^3) = 1;

These evaluate to a polynomial system in the tau variables, which is good, since Maple is generally very good at solving such systems. However, in this case, since these equations have many parameters in addition to the variables, solving using any of the methods in Maple runs out of memory (6GB in my case) fairly quickly. Your best hope, is to specialize some of your parameters, and solve in each case.

John

I am guessing you are using solve(%,x); on this equation?  In that case, Maple will not be able to get an answer unless (unlike this case) the integral has a closed form.  There is no machinery inside solve to get at variables inside definite integrals.

John

Be careful definiting variables as x[i], since this implicitly creates a table named 'x' and something like this can happen to you:

(**) x[1]:=1;
                                   x[1] := 1

(**) x := 10;
                                    x := 10

(**) x[1];
                                     10[1]

 I prefer to use concatenation using 'cat' or the `||` operator for this sort of thing:

(**) x_||1 := 1;
                                   x_1 := 1

(**) for i from 1 to 10 do x_||i := i; end do;

John

In (1), ModuleApply appear to be passing two arguments, but in fact it is passing all of the arguments it received via the special variable _passed (aka args).

(**) foo := proc() print(_passed); end proc: # foo passes all its arguments to print
(**) foo(1,2,3,4);
                                  1, 2, 3, 4
(**) foo(blah);
                                     blah

John

In any case that you want to treat expressions as names, frontend is the one for the job:

(**) frontend(collect, [hh, v^x] );
#                                  2             x
#                              (5 x  - 4 x + 4) v

Two things:

1. Since there are a lot of parameters and the "explicit" solution contains a large non-numeric RootOf() the solution is likely not to be valid for many values of the parameters.   It is almost certainly a better idea, in this case, to specialize parameters and then solve.  Even if you need to do this a lot of times, it will likely be faster and more reliable than substituting in the generic solution.

2.  Use: 1/2, 1/10, and 10^6 instead of .5, .1 and 0.1e7.  Even though they are "mathematically" equivalent, the former are exact and will lead to exact computations, while the latter are floating point numbers that will cause round off errors in subsequent computations.  If you want round-offs then use ?fsolve instead of solve.

RandomTools is using the MersenneTwister PRNG by default. You can set its seed with the ?randomize command, or by calling its SetState command directly (see ?RandomTools,MersenneTwister,SetState ). This should be convincing that that works:

randomize(0); 
setp1 := {$1..100};

to 10 do
    decision := RandomTools:-Generate(choose(setp1)); # chooses 45 every time
    randomize(0);
end do; 

If you are just looking for reproducibility, you should not need to set a seed, since Maple will set itself to the same state every time you start or restart a session.

If you are using solve, you can use the maxsols=# option (see ?solve,details ) to limit the number of solutions returned:

(**) nops( [solve(x^100-1, x, maxsols=10)] );
                                      10

I would use showstat instead of print. Then you don't have to change any kernel or interface settings (but you do get line numbers):

(**) showstat(Student[NumericalAnalysis][Newton]);             

Student:-NumericalAnalysis:-Newton := proc({method::identical(newton) := 'newton'})
   1   return Roots(args,(':-method') = method)
end proc

(**) showstat(Student[NumericalAnalysis][Roots]);
...

To create safe subscripts use ctrl-_ instead of just _.  In the following (1) was made with _, while (2) was made with ctrl-_:

(2) is safe to assign to.  In (1) you'll have this problem, (shown in 1-D input):

> omega := 1; 
                                  omega := 1

> omega[1] := 2;
                                 omega[1] := 2

> omega;
                                     omega

> eval(omega);
                                table([1 = 2])

A first step would be to try the built in importer ?Matlab[FromMFile]

Just define things as expressions. It will make your life easier:

p := 10*x-20*piecewise(x < 2, 0, 2 <= x, x-2);
F := -int(p, x);

Use eval if you want to specilize at x:

eval(F, x=2);

John

What you are seeing are perfectly normal, and expected, artifacts of converting between hardware floating point numbers stored in base 2, and Maple software floats stored in base 10.

(**) evalf[18]( HFloat( HFloat(858/1000.)*HFloat(1000.) ) ); 
                              858.000000000000114
(**) evalf[18]( HFloat( 858. ) );
                              858.

Or:

(**) restart; (SFloatMantissa,SFloatExponent)( HFloat( HFloat(858/1000.)*HFloat(1000.) ), 2 ); 
                             7547047813054465, -43

(**) restart; (SFloatMantissa,SFloatExponent)( HFloat(858.), 2 );
                             7547047813054464, -43

The round off in the hardware loses one binary digit of precision, so back it base 10 it is only accurate to 15 digits.

To avoid the automatic conversion to hardware floats, you can set the enviroment variable ?UseHardwareFloats :

(**) restart: UseHardwareFloats:=false:
(**) a:=Matrix(1..5,1..5,(rand(1..1000))/1000.): b:=a*1000: dismantle(b[4,4]);
FLOAT(3): 858.0000000
   INTPOS(2): 8580000000
   INTNEG(2): -7 

(**) evalf[18](b[4,4]);
                              858.0000000
(**) restart: UseHardwareFloats:=deduced: 
(**) a:=Matrix(1..5,1..5,(rand(1..1000))/1000.): b:=a*1000: dismantle(b[4,4]);
HFLOAT(2): 858.

(**) evalf[18](b[4,4]);
                              858.000000000000114

Looking at the help page ?ImageTools,PlotHistogram I wonder if you are getting larger numbers than you expect because the default is to report the raw numbers of pixels in each bucket.  If so then:

ImageTools:-PlotHistogram(img, 'autorange', 'normalized');

might give you something more like what you expect.

John

This question is asked a lot.  I think the best advice is to use the Standard GUI with different defaults: http://www.mapleprimes.com/questions/95574-Where-Is-The-Classical-Worksheet-maple-10-#comment95582

John