See the attached

simp.mw

If you want

curves, charEq and the real root of charEq, then just run the attached

somePlots.mw

If you change the solve command in this worksheet from

solve(Q1, Q2, Q3,Q4)

to

solve({Q1, Q2, Q3, Q4})

you will get 21 solutions - some real, some complex

Check out the Maple_floats() command.

On my Win7, 64-bit machine

Maple_floats(MAX_FLOAT); returns 1. 10^9223372036854775806

Maple_floats(MIN_FLOAT); returns 1. 10^(-9223372036854775806)

The fundamental problem is the default stepSize/error control which is being used. And (unfortunately for me), the problems are slightly different in Maple 2015 and 2016 and require slightly different solutions.

OP did not specify Maple version, but the attached works on Win7, 64-bit, using either Maple 2015.2 or Maple 2016. There will be a few non-fatal "Error" messages - the reasons for which are discussed in the attached

diffEqProb2.mw

A summary of the remaining (non-fatal) error is that having restricted maxstep or abserr in places. Maple complains about having to work too hard with the error message

Error, (in sol) an excessive amount of work was done, maxstep may be too small

Now I thought I could always get round this by setting maxfun=-1, so removing any limit on the number of function evaluations which are being done - but apparently not so, at least for the lsode method. The alternative of increasing the step size removes the error message about "working too hard", but results in incorrect answers! Rock/HardPlace!

My *pragmatic* solution for this error (when it occurred), was to issue the same command again. Since the second calculation starts from where the first one left off, there is a good chance that second time around it won't hit the maxfun limit. In extremis, this can be repeated multiple times. However a better solution is just to be able to switch the limit off - and wait!

If maxfun=-1 does not remove the limit on the number of calculations, does anyone know what does????

***********************************************************************************

I have noted Doug Meade pointing out "questions" about the precise method by which Maple computes "point" solutions to ODEs. This one does have an impact on the OP's problem, but it is not to difficult to grasp, and is explained in the help files.

Essentially, in order to compute the 'point' solution say, sol(5.0), Maple has to run the ODE solution procedure from 0 to 5.0, which is quite time consuming. But if you subequently want to compute sol(6.0), Maple gets clever. It remembers the solution at 5.0, and therefore only has to run the solution procedure from 5.0 to 6.0. Generally much quicker than having to run the solution procedure from 0 to 6.0.

Maple will continue to do this provide you never reverse the direction of calculation. So if you have a sequence of points at which you require a solution, then ensure that these are monotonic:  calculating sol(6.0) followed by sol(5.0) is seriously inefficient.

I would say always do it in "increasing" order, but if you have boundary conditions at 0, and you want solutions when the independent variable is negative (unusual, but no reason why not!), then you would do it in decreasing order.

Basically always order your points in term of "distance" from your initial value

But is the attached more like what you want

bBall.mw

Looks like Larry and Scotty bump into each other!

randBinSum:=proc( bn )
                              local p, rn;
                           #
                           # Initialise a random number generator
                           # which will produce integers whose
                           # binary representation is at least one
                           # bit less than binNo. Randomize the
                           # seed to ensure that repeated calls
                           # wil get different random numbers
                           #
                              randomize():
                              p:=rand(0..2^(length(bn)-1)):
                           #
                           # Generate such a random number, and
                           # convert it to binary
                           #
                              rn:=convert( p(), binary);
                          #
                          # Add the original number to the generated
                          # random number, and display result in "binary"
                          #
                             return convert
                                       ( convert( rn, decimal, binary )
                                         +
                                         convert( binNo, decimal, binary ),
                                         binary
                                      );
                    end proc:

#
# Example use of above procedure
#
  randBinSum(11101100);

Leaving aside all of the irrelevant statements in your worksheet, such as

> NULL;

your fundamental problem is that you are trying to print numeric values for quantities which depend on 'lm'. However 'lm' is defined in terms of 'mue', and 'mue' is defined in term of 'lm'. Thus anything which depends on either of these variables will never have a numeric value, and hence cannot be printed using a numeric format code.

If I insert a random numeric value for 'lm' in your worksheet (eg 10.0), and comment out those statemenst which I consider to be erroneous/superfluous, then your worksheet executes

With lm:=10, the output of your three print statements is

E=110000;Ud=35000;Imax=35.91;P=1.44550e+07;FR=50;A=0.6;B=0.86258;LC0=2.5877;LD=2.329;LCA=1.0351;R=84.746;BM=1.45;
 % P=1.44550e+07;Id = 413;Bm=1.45;I1=136.23;Bmm=1.4499
 % W1 = 324.53; W2 = 103.27; Lm=9.7507; Sc=0.74404; dzet=0.0001

No (and I don't know why!!)

This question keeps cropping up.

Try typing "3d legends" in the MaplePrimes search box to see previous discussions

If you are interested in speed, - like maybe you have to do this a gazillion tines, then check the third possibility in the attached. It is about 5x faster than either of the methods prposed so far. If speed is not an issue, then don't bother

If you are doing this a lot, then try to reorganise susequent code so that you do not need the Reverse() operation

digToLis.mw

Psi is not a Maple constant. It is a Maple function - so eliminating it from the list of Maple constants isn;t really going to doing anything.

If you wish to use it as an 'ordinary" symbol, then the best way is to use a 'local' declaration, at the top of you worksheet - as in

local Psi;

(if you are unfortunate enough to actually want the original meaniing of Psi, then you can access this with :-Psi)

Use of the 'frequencyscale=absolute' option is going to 'scale' the associated plot.

If you just wnat to change the bincount, then you don't need it. If you want to change the bincount, and then scale the histogram, you will have to scale the KernelDensityPlot by the same amount. But why are you scaling the histogram by an amount whihc is difficult to calculate??

See the attached

HistoProb.mw

NB In order to debug your problem, I had to download the data to someweher appropriate on my machine and modify your worksheet to point at this location on my machine. You will have to adjust the argument to the readdata() command to something appropriate for your machine

Isn't it just simpler to use Maple's recurrence equation solver, rsolve(), as in

rsolve(a(n)=a(n-1)/n, a(k));

which will immediately return

a(0)/GAMMA(k+1)

and all you have to know is that for positive integers GAMMA(k+1) is k!

Or am I missing something?

Check out

?CurveFitting[ArrayInterpolation]

which should cover what you want

Nothing wrong with anything I've seen here, but on the basis that the OP wants to convert "a digit", then the attached is my $0.02

conDig.mw