MaplePrimes Commons General Technical Discussions

The primary forum for technical discussions.

Like most companies today, Maplesoft monitors its website traffic, including the traffic coming to MaplePrimes. This allows us to view statistical data such as how many total visits MaplePrimes gets, how many unique visitors it gets, what countries these visitors come from, how many questions are asked and answered, how many people read but never respond to posts, etc. 

Recently one of our regular MaplePrimes users made the comment that MaplePrimes does not reach new Maple users. We found this comment interesting because our data and traffic numbers show a different trend. MaplePrimes gets unique visitors in the hundreds of thousands each year, and since its inception, it has welcomed unique visitors in the many millions. Based on these unique visitor numbers and the thousands of common searches specifically about Maple that people are doing, we can see that many of these unique visitors are in fact new Maple users looking for resources and support as they begin using Maple. Other visitors to MaplePrimes include people who use Google (or other search engines) to find an answer to a particular mathematics or engineering question, regardless of what mathematics software they choose to use, and Google points them to MaplePrimes. There are some popular posts that were written months, even years ago, that are still getting high visitor views today, showing the longevity of the information on MaplePrimes. 

MaplePrimes gets the majority of its visible activity from a small number of extremely active members. In public user forums around the world, these types of members are given many names – power users, friendlies, evangelists. Every active public user forum has them. On MaplePrimes, it’s this small number of active members that are highly visible. But, what our traffic data reveals is the silent majority. These people, many of them repeat visitors, are quietly reviewing the questions and answers that our evangelists are posting. The silent majority of MaplePrimes visitors are the readers; they are the quiet consumers of information. For every person that writes, comments on, or likes a post, there are thousands more that read it. 

Here are a few more MaplePrimes traffic data points for your reference:

  • MaplePrimes is very international and draws people from all around the world. Here are the top 10 countries where the most MaplePrimes visitors come from:
    1. USA
    2. India
    3. Canada
    4. Germany
    5. China
    6. United Kingdom
    7. Brazil
    8. Australia
    9. France
    10. Denmark
  • Here are the top 5 keywords people are using in their searches on MaplePrimes:
    1. Data from plot
    2. Physics
    3. Sprintf
    4. Size of plot
    5. Fractal
  • MaplePrimes is growing at a very fast rate: Traffic (visitors to the site) and membership size is growing at nearly double the pace it was last year. The total number of posts and questions this year is also much higher compared to the same timeframe last year. 
  • Our top 5 MaplePrimes members have each visited MaplePrimes more than 1200 times and viewed a combined total of more than 10,000 pages (that is total page views, not unique page views). Our top 25 MaplePrimes members have visited at least 250 times each (many of them nearly 1000 times each) and our top 50 MaplePrimes members have visited a combined total of over 23,000 times, visiting nearly 200,000 pages. Thank you! We’re glad you like it. :-)


Maple's dsolve numeric can solve delay ODEs and DAEs as of Maple 18. However, if I am not wrong, it cannot solve delay equations with a time dependent history. In this post I show two examples.

Example 1:

y1(t) and y2(t) with time dependent history. Use of piecewise helps this problem to be solved efficiently. Hopefully Maple will add history soon in its capability.

Example 2: 

This is a very a complicated stiff problem from immunology. As of now, I believe only Maple can solve this (other than RADAR5 from Prof. Hairer). Details and plots are posted in the attached code.


Let me know if any one has a delay problem that needs to be solved. I have tested many delay problems in Maple (they work fine). The attached examples required addtional tweaking, hence the post.


I want to take this opportunity to congratulate and thank Maple's dsolve numeric/delay solvers for their fantastic job. Maple is world leader not because of example1, but because of its ability to solve example 2.




 This code is written by Dayaram Sonawane and Venkat R. Subramnian, University of Washington. You will need Maple 18 or later for this. For those who are wanting to solve these problems in earlier versions, I can help them by offering a procedure based approach (less efficient).

Example1 The first example solved is a state dependent delay problem (


eq1:= diff(y1(t),t)=y2(t);

eq1 := diff(y1(t), t) = y2(t)



eq2 := diff(y2(t), t) = -y2(exp(1-y2(t)))*y2(t)^2*exp(1-y2(t))


 Both y1(t) and y2(t) have time dependent history (y1(t)=log(t) and y2(t)=1/t, t<-0.1). If I am not mistaken one cannot solve this directly using Maple's dsolve numeric command. However, a simple trick can be used to redefine the equations for y1(t) and y2(t) as below


eq3 := diff(y1(t), t) = piecewise(t <= .1, 1/t, y2(t))



eq4 := diff(y2(t), t) = piecewise(t <= .1, -1/t^2, -y2(exp(1-y2(t)))*y2(t)^2*exp(1-y2(t)))


 The problem is solved from a small number close to t = 0 (1e-4) to make Maple's dsolve numeric remember the history till t = 0.1


epsilon := 0.1e-3









[t = 5.0, y1(t) = 1.60942323180838, y2(t) = .199998786891688]




Tweaking the tolerances and epsilon will get the solution even more closer to the expected answers.



 Example 2

 The next problem discussed is very stiff, complicated and as of today, according Professor Hairer (one of the world's leading authority in numerical solutions of ODEs, DAEs), cannot be solved by any other code other than his RADAR (5th order implicit Runge Kutta modified for delay equations, Guglielmi N. and Hairer E. (2001) Implementing Radau IIa methods for stiff delay differential equations. Computing 67:1-12). This problem requires very stringent tolerances. For more information read, I can safely say that Maple can boast that it can solve this delay differential equation by using a switch function (instead of Heaviside/picecewise function). Code is attached below and results are compared with the output from RADAR code.  Note that dsolve/numeric is probably taking more time steps compared to RADAR, but the fact that Maple's dsolve numeric solved this model (which cannot be solved in Mathematica or MATLAB[needs confirmation for MATLAB]) should make Maple's code writers proud. It is very likely that we will be trying to submit an educational/research article on this topic/example soon to a journal. For some weird reasons, stiff=true gives slightly inaccurate results.



radar5data:=readdata("C:\\Users\\Venkat16core-office\\Google Drive\\waltmanproblem\\sol.txt",[string,string,float,string,string,float,float,float,float,float,float]):





["X", "=", 300.000000, "Y", "=", 0.6154486288e-15, 0.3377120916e-6, 0.4221403310e-6, 0.2142554563e-5, 299.9999999, 299.6430338]



eq[1] := diff(y[1](t), t) = -r*y[1](t)*y[2](t)-s*y[1](t)*y[4](t)



eq[2] := diff(y[2](t), t) = -r*y[1](t)*y[2](t)+alpha*r*y[1](y[5](t))*y[2](y[5](t))*H1



eq[3] := diff(y[3](t), t) = r*y[1](t)*y[2](t)



eq[4] := diff(y[4](t), t) = -s*y[1](t)*y[4](t)-gamma1*y[4](t)+beta*r*y[1](y[6](t))*y[2](y[6](t))*H2



eq[5] := diff(y[5](t), t) = H1*(y[1](t)*y[2](t)+y[3](t))/(y[1](y[5](t))*y[2](y[5](t))+y[3](y[5](t)))



eq[6] := diff(y[6](t), t) = H2*(y[2](t)+y[3](t))/(y[2](y[6](t))+y[3](y[6](t)))



H1 := 1/2+(1/2)*tanh(100*t-3500)

H2 := 1/2+(1/2)*tanh(100*t-19700)



alpha := 1.8

beta := 20.

gamma1 := 0.2e-2

r := 50000.

s := 100000.



diff(y[1](t), t) = -50000.*y[1](t)*y[2](t)-100000.*y[1](t)*y[4](t), diff(y[2](t), t) = -50000.*y[1](t)*y[2](t)+90000.0*y[1](y[5](t))*y[2](y[5](t))*(1/2+(1/2)*tanh(100*t-3500)), diff(y[3](t), t) = 50000.*y[1](t)*y[2](t), diff(y[4](t), t) = -100000.*y[1](t)*y[4](t)-0.2e-2*y[4](t)+1000000.*y[1](y[6](t))*y[2](y[6](t))*(1/2+(1/2)*tanh(100*t-19700)), diff(y[5](t), t) = (1/2+(1/2)*tanh(100*t-3500))*(y[1](t)*y[2](t)+y[3](t))/(y[1](y[5](t))*y[2](y[5](t))+y[3](y[5](t))), diff(y[6](t), t) = (1/2+(1/2)*tanh(100*t-19700))*(y[2](t)+y[3](t))/(y[2](y[6](t))+y[3](y[6](t)))



ics := y[1](0) = 0.5000000000e-5, y[2](0) = 0.1000000000e-14, y[3](0) = 0, y[4](0) = 0, y[5](0) = 0.1e-39, y[6](0) = 0.1e-19






 note that compile = true was used for efficiency


[t = 300., y[1](t) = 0.615611371327094e-15, y[2](t) = 0.337706811581908e-6, y[3](t) = 0.422136411682798e-6, y[4](t) = 0.214253771204037e-5, y[5](t) = 299.999986716780, y[6](t) = 299.643054284209]





nd := 1059



["X", "=", 300.000000, "Y", "=", 0.6154486288e-15, 0.3377120916e-6, 0.4221403310e-6, 0.2142554563e-5, 299.9999999, 299.6430338]


 Values at t = 300 match with expected results.


























Download delayimmunetopost.mws

I happen to just have a look at mathematica's imagedeconvolve function .  I had a look at the Examples and saw how a very blurred image of Neil Armstrong standing on the moon with the lunar lander was deconvolved into some really amazing detail. 

I don't believe that image could deconvolve into what they show on that page, It's somewhat misleading.

The only way that deconvolved image could have such great detail is the blurred image used was most likely convolved from the detailed image.  

I wanted to let everyone know that there is a Maple 2015 update available. Maple 2015.1 provides:

  • Support for high-resolution monitors (e.g. 4K, UHD)
  • Updated translations for Brazilian Portuguese, French, Japanese, and Simplified Chinese
  • Enhancements to the Explore command
  • Improvements to the DataSets package
  • Updates to the Microsoft Excel plug-in
  • Enhancements to unit handling
  • A variety of improvements to the math engine, interface, and documentation

To get this update, you can use Tools>Check for Updates from within Maple, or visit Maple 2015.1 Downloads.

If you are a MapleSim 2015 user, you already have this update, as it was part of the MapleSim 2015 installation.


The trailers for the new Star Wars movie (Star Wars: The Force Awakens) introduced a new Droid called BB-8. This curious little guy features a spherical body and a controlled instrumented head. More recently, the BB-8 droid was showcased in a Star Wars celebration event and to many peoples' surprise it is real and not a CGI effect!

We have a Sphero robot from Orbotix here at the office, and there was an immediate connection between BB-8 and the Sphero. All that remains is to add the head!

Many have already put together their version of the BB-8, but I wanted to have a physical model that I can play with in a virtual environment and explore some design options.



To build a model of BB-8 like robotic system in MapleSim (Maplesoft's physical modeling software environment), I first needed a couple things in place before going forward:

  1. A few simple CAD shapes (half-sphere, wheels)

  2. A component to represent the contact between two spheres (both outside contact and inside contact)

I used Maple’s plottools package to build the CAD files I needed. First a half-spherical shape:

Then a wheel:


The next step was to create the contact component in MapleSim. I used a Modelica custom component to bring together vector calculations of normal and tangential forces with a variety of options for convenience into one component:



Build the model:

We start with a spherical shape contacting the ground:


Then we add two wheels inside it, and a hanging mass to keep the reference axis vertical when the wheels turn:


Learning from published diagrams showing the internal mechanism of a Sphero, another set of free wheels improves the overall stability when motion commands are given to the two active wheels:


Now this model can be used to move around the surface by giving speed commands to the individual motors that drive to the two bottom wheels. What is needed next is the head and the mechanism to move it around.

Since the head can move almost freely, independent of body rotation, it has to be controlled via magnetic contacts and a controlled arm.

First, we add the control arm:


Now we need to build the head.

The head has an identical triangle to the one at the end of the control arm. At each vertex there is a ball bearing that would slide on the surface of the main spherical body without friction. The magnetic force between the corresponding vertices of the two triangles is modeled via the available point-to-point force element in MapleSim.



Once assembled, the MapleSim model diagram looks like this:


...and our BB-8 droid looks like this:



Seeing the BB-8 in action:

Now that we have constructed our droid in MapleSim, we can animate and see it in action!


Math powers the world. From tracking the spread of an epidemic to designing a new rocket engine, mathematical equations allow us to understand a challenge and formulate an approach to solving it. Everywhere around us, math is ubiquitous; an equation determines how your thermostat controls your home furnace; a mathematical algorithm is used to encode the signal from your cell phone. More than ever, we rely on mathematics to make our lives better. And continually, our mathematical techniques get more refined as we solve more and more complex problems.

Someone asked on about plotting x*y*z=1 and, while it's easy enough to handle it with implicitplot3d it raised the question of how to get nice constained axes in the case that the x- or y-range is much less than the z-range.

Here's what WolframAlpha gives. (Mathematica handles it straight an an plot of the explict z=1/(x*y), which is interesting although I'm more interested here in axes scaling than in discontinuous 3D plots)

Here is the result of a call to implicitplot3d with default scaling=unconstrained. The axes appear like in a cube, each of equal "length".


Here is the same plot, with scaling=constrained. This is not pretty, because the x- and y-range are much smalled than the z-range.


How can we control the axes scaling? Resizing the inlined plot window with the mouse just affects the window. The plot itself remains  rendered in a cube. Using right-click menus to rescale just makes all axes grow or shrink together.

One unattractive approach it to force a small z-view on a plot of a much larger z-range, for a piecewise or procedure that is undefined outisde a specific range.

                        if abs(z)>200 then undefined;
                        else x*y*z-1; end if;
                      end proc,
                      -1..1, -1..1, -200..200, view=[-1..1,-1..1,-400..400],
                      style=surfacecontour, grid=[30,30,30]);

Another approach is to scale the x and y variables, scale their ranges, and then force scaled tickmark values. Here is a rough procedure to automate such a thing. The basic idea is for it to accept the same kinds of arguments are implicitplot3d does, with two extra options for scaling the axis x-relative-to-z, and axis y-relative-to-z.

implplot3d:=proc( expr,
                  {scalex::numeric:=1, scaley::numeric:=1} )
   local d1, d2, dz, n1, n2, r1, r2, rngs, scx, scy;
   uses plotfn=plots:-implicitplot3d;
   (n1,n2) := lhs(rng1), lhs(rng2);
   dz := rhs(rhs(rng3))-lhs(rhs(rng3));
   (scx,scy) := scalex*dz/(rhs(rhs(rng1))-lhs(rhs(rng1))),
   (r1,r2) := map(`*`,rhs(rng1),scx), map(`*`,rhs(rng2),scy);
   (d1,d2) := rhs(r1)-lhs(r1), rhs(r1)-lhs(r1);
   plotfn( subs([n1=n1/scx, n2=n2/scy], expr),
           n1=r1, n2=r2, rng3, _rest[],
end proc:

The above could be better. It could also detect user-supplied custom x- or y-tickmarks and then scale those instead of forming new ones.

Here is an example of using it,

implplot3d( x*y*z=1, x=-1..1, y=-1..1, z=-200..200, grid=[30,30,30],
            style=surfacecontour, shading=xy, orientation=[-60,60,0],
            scalex=1.618, scaley=1.618 );

Here is another example

implplot3d( x*y*z=1, x=-5..13, y=-11..5, z=-200..200, grid=[30,30,30],
            style=surfacecontour, orientation=[-50,55,0],
            scaley=0.5 );

Ideally I would like to see the GUI handle all this, with say (two or three) additional (scalar) axis scaling properties in a PLOT3D structure. Barring that, one might ask whether a post-processing routine could use plots:-transform (or friend) and also force the tickmarks. For that I believe that picking off the effective x-, y-, and z-ranges is needed. That's not too hard for the result of a single call to the plot3d command. Where it could get difficult is in handling the result of plots:-display when fed a mix of several spacecurves, 3D implicit plots, and surfaces.

Have I overlooked something much easier?


I would like to announce a new unofficial record computation of the MRB constant that was finished on Sun 21 Sep 2014 18:35:06.

I really would like to see someone beat it with Maple!

It took 1 month 27 days 2 hours 45 minutes 15 seconds. I computed 3,014,991 digits of the MRB constant, (confirming my previous 2,00,000 or more digit computation was actually accurate to 2,009,993 digits), with Mathematica 10.0. I Used my version of Richard Crandall's code:



(*Fastest (at MRB's end) as of 25 Jul 2014.*)


prec = 3000000;(*Number of required decimals.*)ClearSystemCache[];

T0 = SessionTime[];

expM[pre_] := 

  Module[{a, d, s, k, bb, c, n, end, iprec, xvals, x, pc, cores = 12, 

    tsize = 2^7, chunksize, start = 1, ll, ctab, 

    pr = Floor[1.005 pre]}, chunksize = cores*tsize;

   n = Floor[1.32 pr];

   end = Ceiling[n/chunksize];

   Print["Iterations required: ", n];

   Print["end ", end];

   Print[end*chunksize]; d = ChebyshevT[n, 3];

   {b, c, s} = {SetPrecision[-1, 1.1*n], -d, 0};

   iprec = Ceiling[pr/27];

   Do[xvals = Flatten[ParallelTable[Table[ll = start + j*tsize + l;

        x = N[E^(Log[ll]/(ll)), iprec];

        pc = iprec;

        While[pc < pr, pc = Min[3 pc, pr];

         x = SetPrecision[x, pc];

         y = x^ll - ll;

         x = x (1 - 2 y/((ll + 1) y + 2 ll ll));];(*N[Exp[Log[ll]/ll],

        pr]*)x, {l, 0, tsize - 1}], {j, 0, cores - 1}, 

       Method -> "EvaluationsPerKernel" -> 4]];

    ctab = ParallelTable[Table[c = b - c;

       ll = start + l - 2;

       b *= 2 (ll + n) (ll - n)/((ll + 1) (2 ll + 1));

       c, {l, chunksize}], Method -> "EvaluationsPerKernel" -> 2];

    s += ctab.(xvals - 1);

    start += chunksize;

    Print["done iter ", k*chunksize, " ", SessionTime[] - T0];, {k, 0,

      end - 1}];

   N[-s/d, pr]];

t2 = Timing[MRBtest2 = expM[prec];]; DateString[]


MRBtest2 - MRBtest2M



I used a six core Intel(R) Core(TM) i7-3930K CPU @ 3.20 GHz 3.20 GHz with 64 GB of RAM of which only 16 GB was used.

t2 From the computation was {1.961004112059*10^6, Null}.




For all real a, the partial sums sn= sum((-1)^k (k^(1/k) -a), k=1..n) are bounded so that their limit points form an interval [-1.+  the MRB constant +a, MRB constant] of length 1-a, where the MRB constant is limit(sum((-1)^k*(k^(1/k)), k = 1 ..2*N),N=infinity).

For all complex z, the upper limit point of  sn= sum((-1)^k (k^(1/k) -z), k=1..n) is the  the MRB constant.

We see that maple knows the basics of this because when we enter sum((-1)^k*(k^(1/k)-z), k = 1 .. n) 

maple gives

sum((-1)^k*(k^(1/k)-z), k = 1 .. n)

you can change help of older maple version to 18 by this command:


for example if you download DirectSearch optimization package it's help don't open in maple 18 because in maple 18 .hdb converted to .help and you can do this convert by HelpTools:-Database:-ConvertAll():

DirectSearch version 2 created for maple 13 and i converted it's help to 18.

after i typed this command maple 18 wrote: 

"Converting G:\\Program Files\\Maple 18\\lib\\DirectSearch.hdb to G:\\Program Files\\Maple 18\\lib\\"
Warning, .hdb help databases are deprecated, 'G:\Program Files\Maple 18\lib\DirectSearch.hdb' will not be used, see ?HelpTools,Migrate help page for more information.

and when try again it worked properly and DirectSearch help opened.

Some years ago member William Fish started a long discussion in part about a numeric integral involving high parameter (high oscillation) Bessel J0. That numeric integration task appeared in a Bitwise Magazine article.

At that time even obtaining numeric results involved extra effort such as handling real and imaginary components of the integrand separately, and requesting particular methods (sometimes hacked, to bump up the subinterval limit, for very high parameter values).

That led to a post where I showed that the result could be obtained quickly by using a fast compiled BesselJ (J0) from an external library along with a modified low-level call to a particular evalf/Int solver.

And sometime after that a numeric result for the real & imaginary split integrand became much more readily (if not quickly) available by using a new `maxintervals` option of evalf/Int to specify the maximal number of subintervals for the particular solver.

Maple 18 has its own compiled implementations of the Bessel functions for "hardware" (double) precision arguments. So now the numeric evaluations of the integrand are computed much faster.

Using Maple 18.00 on 64bit Windows 7 the same numeric results obtain in under a second, in a simple, single call to evalf,Int.


  evalf(Int(BesselJ(0, 50001*x)*x*exp(I*(355*x^2*1/2)), x = .35 .. 1))
memory used=9.28MiB, alloc change=32.00MiB, cpu time=437.00ms, real time=441.00ms, gc time=0ns

                           -8                 -8  
             3.181753502 10   - 7.798301124 10   I


  evalf(Int(BesselJ(0, 10000*x)*x*exp(I*(355*x^2*1/2)), x = .35 .. 1))
memory used=6.83MiB, alloc change=32.00MiB, cpu time=218.00ms, real time=211.00ms, gc time=15.60ms

                            -7                 -7  
             -2.007752340 10   + 4.275388462 10   I


Of course the ramifications of fast, compiled Bessel functions at double precision extend much farther than just this one example. But I like seeing the speed improvement in terms of a concrete example.


Yesterday afternoon, we updated MaplePrimes. The purpose of the update was primarily to squash some bugs and improve user experience.

Highlights of the update include:

  • The ordering of replies has been corrected, as described in this post by Carl Love.

  • We fixed a problem whereby some members were unable to attach a file to a question or post.

  • Flagging a comment now works correctly.

  • Broken images that were appearing on some of our older posts have been restored. In addition, some older posts had incorrect dates, and these have been restored.

  • Some embedded links to user profiles or messages were resulting in errors, and have been corrected.

  • After receiving a badge, members will now be notified via a pop-up message.

A number of other small improvements were made as well.

As always, thank you for letting us know when you encounter a problem, and please continue to do so. We take note of everything that you report, and we try our best to prioritize and take care of the issues.


Voting is now open for the next individual prize to be awarded as part of the Möbius App Challenge.  The winner will receive an Xbox One Prize Pack! 

Here are the finalist Apps:

Note that, if you ever have any problems viewing Apps in your browser, or simply want to work offline, you can always download a Möbius App and view it in Maple or the free Maple Player. To download a Möbius App, follow the link to the App and then click on the Download button near the top left of the page.

You can vote for your favorite through our Facebook page or, if you’re not on Facebook, send an email with your vote to

And remember, we are now accepting entries for the next quarterly prize. You could win a Music Prize Pack, including the 64GB 5th Generation Apple iPod Touch, Sennheiser In-Ear Noise Cancelling Headphones and the Bose SoundLink Bluetooth Speaker III!  See the Möbuis App Challenge for details.

Voting closes April 25th, 2014.

I'll start with a quick positive.  One of the great advantages of upgraded software is the wealth of new features that we all get to play around with.  .. and then I will counter that with a great disadvantage, and that is, we all just about get familiar and comfortable with all the new features then BAM! a new version is released.  Of course we're then mesmorized once again by all the new bells and whistles and maybe even a couple of great celebrations occur with nice small updates throughout the year.  The other downside is that even though a large number of bugs may have been fixed a number of new ones are broght in with those new features. 

A side effect of a fast release is there are fewer and fewer applications associated with a release, and that is apparent in the application center.  Although mobius apps and the maple cloud may have also had some impact on that as well.

Now this is pale in comparison to book writers who scramble to keep their books current with new software.  I will quote a section from the introduction in the book Essential Maple 7 which highlights the problems the author had way back then .. I can't imagine how they feel now but here's the passage ...

"Indeed, one reason that there was so much time between the first and second
editions of this book is precisely that Maple has been evolving so rapidly in the
last few years, too rapidly for me to revise this book (much less complete my
others) while coping with my other duties."

That just hits the nail on the head, if you think Maple was evolving fast back then, the furious rate that upgrades are released now I would think authors have an almost impossible task to keep up. 

There are many that would agree with the author, that Maple is advancing so rapidly that we barely have time to gather our thoughts.  Maybe a solution is that we should slow down and create a much more polished piece of software, but again the caveat to that is our competition might just jump out in front.  However the norm today is that each new year represents a new release of software and we all celebrate when that happens.  If life seemed rushed back when Maple 7 was released I can't imagine what it'll be like 10 years from now when Maple 28 rolls around. 


It seems that


Limit(N+(sum((-1)^n*Sum(1/n^x, x = 1 .. N), n = 1 .. infinity)), N = infinity)=log(2)

 evalf(300+sum((-1)^n*(Sum(1/n^x, x = 1 .. 300)), n = 1 .. infinity), 30)



 sum(1/n^x, x = 1 .. infinity)



First 6 7 8 9 10 11 12 Last Page 8 of 78