series is a very low-level routine used by a lot of other Maple routines, and the efficiency of a fair bit of Maple depends on series being quite efficient. This is the main reason that series does not ``simplify'' as much as one would hope.

It is wise to revisit this issue.  First, it makes sense to have a low-level routine which computes with polynomials (and rational functions) in a very efficient manner.  Breaking that would cripple Maple.  But does it mean that that has to be the same routine that users use for high-level series computation?  Of course not!  This is another artifact of history.

Personally I always use MultiSeries[series] for my high-level computations.  It uses a stronger normalizer than series.

Note that while it is possible to create objects (via constructors and modules, as shown above), it is not necessarily always a good idea to do so.  Maple does not have many supporting tools for OO-style programming, so that this style can make things more difficult; for example, Maple's debugging tools are not at all well-suited for the task [this is not a complaint, BTW].

Not that this style should be avoided at all costs - I myself have some code which uses this style.  It is a useful encapsulation mechanism for certain types of data (where you need mutability but in a local, controlled manner).  But you will find that the style that works best in Maple is where:

1. your functions all have functional interfaces
2. your implementations work with (local) mutable state

This is how much of Maple's own library is written.

To the system administrators: this thread is a really good example of how utterly useless the <maple> tag now is on this site.  Please fix it.  Being able to display mathematics nicely was a good addition to this site, which now simply does not work anymore.

Good thing we still have the TTY version, which we can use for getting ASCII-based output to show in our posts.  Otherwise this site would have been irredeemably broken by the latest ``update''.

Your best bet is to use Maple's built-in export to RTF.  Cut-and-paste sometimes works, it really depends on the expression and which version of the GUI you're using (neither is flawless).  Or you could paste in images, as is done for HTML export.  But the HTML export does not always respect window widths, so that may not always give you exactly what you expect either.

In other words, experiment -- it is very likely that you will be able to achieve what you are looking for, but there is no solution that seems to work flawlessly.

This is a fascinating thread.  We can clearly see that there are lots of different Maple features that ought to work as a way to display function tables.  But notice how the ones that got the 'best' answers are the older features, while the newer features mostly generated "maybe you can use this, but I can't figure it out from the help pages".

What is the return-on-investment for Maplesoft to create (and market) all these new features when the experts can't even figure out how to use them?  Just as bad, those features don't even come to mind?

I think there is also a pointy-clicky way of doing that, which ends up looking really nice, but I don't know how to do it.  Hopefully someone will enlighten us.

I would like it if there were a nice way to programmatically insert a nice table like that in the GUI, but alas I don't think that's possible.  I would be most pleased to be wrong on that one.

You cannot force fsolve to give repeated roots in general. However, the SNAP (Symbolic-Numeric Algorithms for Polynomials) package does. I think it first went in to Maple around Maple 8. It has various tools that should help you with your numerical search for multiple roots.

Another possibility is to take a look at Sturm sequences, sturmseq or the realroots function.

Especially since the Statistics package is, generally, much better?

This is now a trend - users of Statistics:-Sample seem to uniformly use it the "slow" way.  That indicates to me that this should become an FAQ, and the documentation should be improved to steer people away from this.  Otherwise they think that Maple is really slow for this kind of stuff, which is absolutely false.

Even better, this probably ought to be in some kind of newfangled mint-like-extension to Standard.  Now that would really help users!

There are few people on this board (and at Maplesoft) who actually know OpenMaple for Java, and they don't always check here too regularly.  Wait 4-5 days, you'll hopefully get an answer by then.

In the meantime, if you gave more details as to what exactly 'failed', that might help get you better answers.

It seems related to the Simpson's method. First, a few improvements to you code: 1. Don't use subs, use eval instead. Wherever you learned to use subs, throw that book out, it is too old. For example, you should use s0:=proc(tau) piecewise( tau < evalf(exp(-27)), 0, eval(s(t),g(tau)) ) end; for your definition of s0. 2. Don't use % in a procedure. This really leads to all sorts of problems. 3. It is a good idea to use long names in a procedure rather than assuming that 'with' has been done. 'with' is useful for interactive use, but should be avoided when writing code. When debugging, it is a good idea to name intermediate steps. So your m0 should be written as

 m1:=proc(t1)local g2,g3, g4,g5,m1,gg,xi,hh;
    if evalf(t1) < evalf(exp(-18.5)) and evalf(t1) > evalf(exp(-27)) then
        m1:=evalf((subs(t=t1,k=1.111111111,2*ln(4*Pi*k^2*t)))^(-3))
    else 
        gg := Int((eval(g1(xi),{k = 1.111111111,h=0.00000000001,q=0})), xi=exp(-27.0)..t);
        hh := ApproximateInt(gg, method=simpson,partition=1); # note the 1 instead of 100 here!
        g2 := eval(hh, {s=s0,t=t1});
        g3 := evalf(g2);
        g4 := eval(,k*s0(exp(-27)),k=1.1111111);
        g5 := evalf(g4+g3);
    end if;
end proc;

If you then do printlevel := 10; before you invoke m1 you will see that already in hh there is a problem, which just propagates from there.

As I have mentionned before, this kind of inlining and optimization of Maple code can actually be automated via partial evaluation. Thanks for providing an additional test case.

There used to be a Maple-specific Journal ['MapleTech', which was a Birkhauser journal, which evolved from the 'Maple Technical Newsletter'] but it has long been defunct. Unlike Mathematica, it seems that the Maple community has not been able to sustain something like The Mathematica Journal. On the other hand, mapleprimes is much more active than anything that the Wolfram universe has to offer.

This is a first order system with constant coefficients. Unless they are equal, the answer is a superposition of exponentials. Thus for initial conditions 0 at 0, you get only the boring answer - N1 = N2 = 0, which dsolve gives you quite easily. Even when the lambdas equal, that is still the answer. With other initial conditions, the answer is more interesting. For n nucleides, it is probably not that hard to solve this problem. The resulting Matrix is quite simple, and you ought to be able to get a pattern for the eigenvalues.

To save us the trouble of retyping everything, could you add a link to you .mw so we can download it?