@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.

@nm The usual thing would be to utilize something like libpng.

I see such a dll in the gstreamer folder in the bin.X86_64_WINDOWS folder of my Maple 18 (but not so with Linux 64bit).

It would be nice if this could be used by ImageTools:-Read.

[edit] This is indeed an oft requested feature. It may be of interest that DocumentTools:-SetProperty could apply a PNG image to a LabelComponent as far back as Maple 11.

@Carl Love The following are both results as "false", in Maple 18.01 (with no updated Physics add-on/patch).

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, `.`));
                             false

type(z1, ('`.`')(anything, anything));
                             false

kernelopts(version);
   Maple 18.01, X86 64 WINDOWS, Mar 28 2014, Build ID 935137

But in Maple 17.02 those results were both "true". Now, those both use `.` and not :-`.` so it seems that loading the Physics package has rebound `.`. I don't know what that package's author intends. In Maple 17.02 z1 comes out as a function call of Physics:-`.`, while in stock Maple 18.01 it comes out as a function call of Physics:-`*`.