Exporting As > Maple input (.mpl) produces:

#
#
# Richard Messeder    Date: 2008.05.07
# UNH / Durham
Document to test Maple document capabilities; there are keywords here even though this is a text section: how does one type in regular words in text?
`output redirected...`print(); # input placeholder
# http://pubpages.unh.edu/~rlo9/
# Thisis a port of an earlier project to help me learn Maple 12.
#
 
So, this section does seem to have been generated as ordinary text.

plots[display] is the long name, you can use just 'display' if previously did

with(plots):

about long names or 1D output. It is for the humans interacting with the computer,  that it makes a big advantage good typesetting and compact notation in case of long, complex results. Ie it is an issue of efficiency in the machine-human  interface.

about long names or 1D output. It is for the humans interacting with the computer,  that it makes a big advantage good typesetting and compact notation in case of long, complex results. Ie it is an issue of efficiency in the machine-human  interface.

and it has the additional "advantage" say, to show the bug explicitly. I would expect 'undefined' instead of 0 at the origin.

f := x*y*(x^2-y^2)/(x^2+y^2);
f1 := piecewise(And(x=0,y=0), 0, f);
g:=unapply(f1,x,y);
g(0,0);
                                  0
g(x,y) assuming x<>0, y<>0;

x*y*(x^2-y^2)/(x^2+y^2);

Maxima? Axiom?

You may have missed this blog about an interview to Gaston Gonnet with historical details.

That list does not include several dot versions (and the like, as Maple V Release 4.00b). The date that I have for Maple 10.02 is in December 2005 (or a bit earlier), but then there was 10.03, 10.04 and 10.06 along 2006.

is the result of executing the above lines in Maple 8.

The problem is that 'solve' produces a set of an equation. Hence 'N' becomes:

You could do instead:

N := unapply(subs(%,n), r, p, b);

is the result of executing the above lines in Maple 8.

The problem is that 'solve' produces a set of an equation. Hence 'N' becomes:

You could do instead:

N := unapply(subs(%,n), r, p, b);

too seriously, because depending on the sequence of evaluations, different locations arise for this candidate singularity.

If I change to:

for i to 120 do
F(i/4*10^(-10));
end do;

I get instead:

Error, (in F) cannot evaluate the solution further right of .24988107e-8, probably a singularity But increasing Digits:

Digits:=30:
F:=dsolve({sys, x(0)=1,  P1(0)= 10^5, P2(0) = 10^5, D(x)(0)=0},fcns, numeric, abserr=500);

Error, (in F) cannot evaluate the solution further right of .10912725e-16, probably a singularity

 And the values that I see do not seem to indicate that the functions and/or their derivatives are close to diverge. To the contrary, the issue may be that the first derivatives vanish.

too seriously, because depending on the sequence of evaluations, different locations arise for this candidate singularity.

If I change to:

for i to 120 do
F(i/4*10^(-10));
end do;

I get instead:

Error, (in F) cannot evaluate the solution further right of .24988107e-8, probably a singularity But increasing Digits:

Digits:=30:
F:=dsolve({sys, x(0)=1,  P1(0)= 10^5, P2(0) = 10^5, D(x)(0)=0},fcns, numeric, abserr=500);

Error, (in F) cannot evaluate the solution further right of .10912725e-16, probably a singularity

 And the values that I see do not seem to indicate that the functions and/or their derivatives are close to diverge. To the contrary, the issue may be that the first derivatives vanish.

I can understand, thought not justify, that a developer closes a SCR as "works as designed" when there is a design bug  because psicologically  cannot recognize the problem. What I cannot understand is that  those in the role of quality control  validate this behavior.

g:=N->add(n,n=select(isprime,[$1..N]));
g(5);
                                  10

g:=N->add(n,n=select(isprime,[$1..N]));
g(5);
                                  10