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

There is also Prof. Mike Monagan's recent item on the Application Center (and which was also linked from the last issue of the Maple Reporter).

acer

Your command worked fine for me in 18.02,

kernelopts(version);
   Maple 18.02, X86 64 WINDOWS, Oct 20 2014, Build ID 991181

acer

Try `mul` rather than `product`.

acer

The improvement in rendering of 2-D plots deserves a screenshot comparison.

Here is Maple 18.00 (which also looks similar in previous versions).

Notice how the curve seems to be comprised of a collection of roughly joined segments. This was not really fixable by increasing numpoints (with or without adaptive plotting). The data is adequate to get a smooth .eps export; it's just the rendering in the GUI which is at issue.

And here it is in 18.02.