I see nothing unfriendly about your question.

I suspect that you're right -- it need not be coded that way. It might instead begin like, say,

R := Matrix(n, n, ':-shape' = ':-triangular'[':-lower']);

and end with something like,

Digits:=oldDigits:
map[':-inplace'](evalf,R);

There are lots of ways to get similar effects, of course. I suspect that we are seeing some part of the personal style of the code's author. (To me, it looks old-fashioned, almost redolent of linalg.)

I suspect that the author was not especially concerned about efficiency. The author might have felt that this is a routine more for exposition of method than for attaining maximal efficiency, being part of the Student body of code. Examples are likely not large enough or repeated often enough to make the efficiency concerns most crucial. If efficiency were more crucial here then better to operate at hardware precision. And less need to round down the result.

All the above is my best guess. I cannot prove any of it.

acer

@nm There is a separate procedure `evalf/AiryBiZeros`.

Maple has an extension mechanism, which allows evalf to utilize a custom procedure.

restart:

`evalf/foo` := proc(x) x!; end proc:

evalf( foo(3) );                    

                                       6

There are examples of this on the help page for topic evalf,details.

In my Chrome (version 25.0.1364.152) on 64bit Linux the voting toggles (upvote, favorite, best-answer) don't do anything.

acer

You have two sets of braces (nested) in your assignment to `init4`. Remove the outer ones.

acer

In 1D Maple notation the following returns the scalar value 2. Note the space after the first closing parenthesis (round bracket).

    Vector([1,2]) (2);

In 2D Math input mode it produces Vector([2,4]) since the space is interpreted as implicit multiplication.

@9colai By default the plotting mechanism will try to use evalhf to evaluate the expression. Some of the multiplicands' exponents are out of range for double precision, however.

There are several ways around this.

For this particular example, expanding the product combines some of the exponents. Ie, in Maple 18.01, these both work.

plot(expand(u));
plot(simplify(u));

Other workarounds can involve side-stepping evalhf mode. One way is to set Digits higher than evalhf(Digits).

Digits:=17:
plot(u);

Or, if you don't want to set Digits high,

Digits:=10:
UseHardwareFloats:=false:
plot(u);

@wo0olf There are details inside the numerical pdsolve routines which will get printed if you execute the command,

infolevel[`pdsolve/numeric`]:=2:

before you call pdsolve(..., numeric).

Execute the command I showed (or set the value higher, say to 3), and then call the solver as you did before. That is all.

@ctc In your latest comment you are still missing proper syntax for the multiplication of terms y(x) and (20-y(x)), which I pointed out before.

It is sometimes useful to make the condition explicit, as an assumption. Sometimes simplification with the `symbolic` option to ignore branch cut details leads to confusion for some people, when they forget later on that the results were conditional.

ee := -ln(-a/(b-c)):
combine(ee) assuming a/(c-b)>0;

                            /  b - c\
                          ln|- -----|
                            \    a  /

You appear to be missing the multiplication sign between y(x) and (20-y(x)).

Are you looking for something remotely like this (not making any attempt at the Order question)?

des := diff(y(x), x) = (1/80)*(y(x))*(20-y(x)):
ics := y(0) = 1:
soln := dsolve({des, ics}, {y(x)}, series);
approx := eval(y(x), convert(soln,polynom));
exact := eval(y(x), dsolve({des, ics}, {y(x)}));
plot( [approx, exact], x=0..20, color=[red,blue], linestyle=[1,2] );

acer

Why do you think that the two forms that you first show are equal?

restart:

eq:=c=a+b*exp(-k):

s1 := solve( eq, k );

                                      /  a - c\
                             s1 := -ln|- -----|
                                      \    b  /

s2 := ln( b/(c-a) );

                                      /  b   \
                              s2 := ln|------|
                                      \-a + c/

eval( [s1, s2], [ a=c+1, b=1 ] );

                                [-I Pi, I Pi]

Your guess about the ordering of terms in a sum being according to lexicographic order is also not right, I believe. It's true that the behavior changed a few years ago for sets, but not for sums and products. I believe that it is still ordering by address, for which there is some evidence. Ie,

restart:
ln( b/(c-a) );
                                    /  b  \
                                  ln|-----|
                                    \c - a/

restart:
-a+c:
ln( b/(c-a) );
                                   /  b   \
                                 ln|------|
                                   \-a + c/

I believe that you can also force re-ordering of terms internal to the sum -- even in the same session -- through some creative use of the `sort` command.

acer

@Kitonum 

restart:

H:=`%+`($1..20):

InertForm:-Display(H=InertForm:-Value(H));

@Aakanksha Ensure that you are trying it with single left-quotes, as,

convert(%,`+`);

and not with single right-quotes, as,

convert(%,'+');

As you have written it, what you're seeing it a consequence of premature evaluation. sum is receiving identically 0 as its first argument, not 0^m.

Now, '0^m' becomes zero as a result of automatic simplification. So delaying evaluation with quotes won't help.

But the prefix operator does allow the delay quotes. Eg,

sum( '`^`'(0,m), m=0..3 );
                               1

Here is something that looks a bit more like a bug, IMO,

sum( '`^`'(0,m), m=0..infinity );
                               0

acer

You might try Robert Israel's factrix command.  See this earlier post. Or do you have the goal of wanting something that also figures out the common factor for you?

acer