In Maple 9,

> restart:

> P:=sum(1/(6*k+1)!, k= n..infinity): 
> lprint(P);

1/(1+6*n)!*hypergeom([1],[n+1, n+1/3, n+1/2, n+2/3, n+5/6, 7/6+n],1/46656)

> eval(P,n=0);

                  hypergeom([], [1/3, 1/2, 2/3, 5/6, 7/6], 1/46656)

> evalf(%);

                                     1.000198413

> convert(eval(P,n=0),StandardFunctions):    
> simplify(combine(radnormal(%))): lprint(%);

1/6*(exp(2)-1+exp(3/2)*cos(1/2*3^(1/2))+3^(1/2)*exp(3/2)*sin(1/2*3^(1/2))-exp(1/2)*
cos(1/2*3^(1/2))+3^(1/2)*exp(1/2)*sin(1/2*3^(1/2)))*exp(-1)


> eval(P,n=1);

            1/5040 hypergeom([1], [4/3, 3/2, 5/3, 11/6, 2, 13/6], 1/46656)

> evalf(%);

                                   0.0001984128589

And then in Maple 9.5 it returned an expressed which did not involved `n` for sum(1/(6*k+1)!, k= n..infinity) as Axel showed, and got the same wrong answers as Maple 16/17 etc.

acer

In Maple 9,

> restart:

> P:=sum(1/(6*k+1)!, k= n..infinity): 
> lprint(P);

1/(1+6*n)!*hypergeom([1],[n+1, n+1/3, n+1/2, n+2/3, n+5/6, 7/6+n],1/46656)

> eval(P,n=0);

                  hypergeom([], [1/3, 1/2, 2/3, 5/6, 7/6], 1/46656)

> evalf(%);

                                     1.000198413

> convert(eval(P,n=0),StandardFunctions):    
> simplify(combine(radnormal(%))): lprint(%);

1/6*(exp(2)-1+exp(3/2)*cos(1/2*3^(1/2))+3^(1/2)*exp(3/2)*sin(1/2*3^(1/2))-exp(1/2)*
cos(1/2*3^(1/2))+3^(1/2)*exp(1/2)*sin(1/2*3^(1/2)))*exp(-1)


> eval(P,n=1);

            1/5040 hypergeom([1], [4/3, 3/2, 5/3, 11/6, 2, 13/6], 1/46656)

> evalf(%);

                                   0.0001984128589

And then in Maple 9.5 it returned an expressed which did not involved `n` for sum(1/(6*k+1)!, k= n..infinity) as Axel showed, and got the same wrong answers as Maple 16/17 etc.

acer

@martin_z I believe that the option -strict32bit could be added to the appropriate field in the Maple 16.app package's info.plist file.

@martin_z I found the NAG,Platforms help-page and it does state that for OSX on Intel the (only) supported NAG C Library version is CLMIN08DGL which is the 32bit (i386) version of the Mark 8 version of that product. So that part seems correct.

But I don't quite see why your machine must (or can) be 32bit. This page suggests that 32bit Maple 16 is supported on OSX 10.6, but you have indicated that your operating system is 10.7.5 (Lion) and as far as I can tell that is an x86-64 platform for 64bit Macs. By default Maple will run 64bit binaries on OSX 10.7.5, I believe.

I don't have access to a purely 32bit OSX Intel machine any more. What do you get if you execute the Maple command,

            kernelopts(wordsize);

If that returns `64` then I suspect that your Maple 16 is running in 64bit mode. If it returns `32` then your running Maple and NAG C Library might match and the problem could be something else (path to the dylib, say).

[edited] I recall that there may be a way to force Maple 16 to run 32bit mode on OSX, since the "universal binaries" on OSX are a fusion of i386/x86-64 (Mach-O) binary files. I've never done it myself, but you may be able to force it by changing Properties of the Standard GUI (executable, launcher... I don't know). Roman Pierce might know.

@Markiyan Hirnyk The NAG C Library is a 3rd party product from NAG. It is not bundled in Maple.

The NAG Connector Toolbox in Maple links the two products togerther so that functions from the NAG C Library can be accessed from a Maple session.

If you don't have an appropriate version of the NAG C Library installed then none of the computational functions of the Toolbox will work.

If you don't have a valid license for the NAG C Library them the subset of its functions that are license locked will not work.

Martin's problem appears to be that he has Maple 16 and has purchased a version of the NAG C Library, but the Toolbox commands still don't work. I suspect the problem is that only the 32bit PowerPC version of the Toolbox was ever supported for OSX (and I could be wrong), but I don't have acess right this moment to the complete documentation or a 32bit Intel OSX box.

@martin_z What architecture is your Mac? Is it a 64bit Intel chipset?

What platform of the NAG C Library did you install? (The name of the package file should be enough to figure out the exact version and intended platform.) Which version of Maple are you running?

The 32bit vs 64bit aspect and the platform architecture (Intel vs PowerPC, say) are both qualities that should match across your Maple version, NAG Library, and host architecture. Full details, including specs on your machine, would likely help diagnose the situation.

@herclau Add the options `filledregions` and `coloring` to the call to plots:-implicitplot.

filledregions=true, coloring=[blue,white]

@herclau Add the options `filledregions` and `coloring` to the call to plots:-implicitplot.

filledregions=true, coloring=[blue,white]

@Alejandro Jakubi You are technically wrong in the blanket assertion that Maple does not allow programmatic creation and insertion of embedded components. It can be done in Maple 17, just with some Maple code, even to the point of getting the names of introduced components as return values. It would be correct to say that it currently is not possible in common practice, nor in a practical fashion. It is currently not at all easy, nor documented, nor possible to validate properly -- but it is possible.

You're warning is about coding with embedded components altogether, and would also relate to any other example for which a solution used them. I would fully agree with the view that properly functional, fully programmatic embedded components would be much superior to the mouse-pointer driven functionality provided at present. And that is why I mentioned the need for a validating Worksheet XML schema here, in a post dedicated to functionality suggestions, since I feel it is a necessary step towards that.

@Alejandro Jakubi You are technically wrong in the blanket assertion that Maple does not allow programmatic creation and insertion of embedded components. It can be done in Maple 17, just with some Maple code, even to the point of getting the names of introduced components as return values. It would be correct to say that it currently is not possible in common practice, nor in a practical fashion. It is currently not at all easy, nor documented, nor possible to validate properly -- but it is possible.

You're warning is about coding with embedded components altogether, and would also relate to any other example for which a solution used them. I would fully agree with the view that properly functional, fully programmatic embedded components would be much superior to the mouse-pointer driven functionality provided at present. And that is why I mentioned the need for a validating Worksheet XML schema here, in a post dedicated to functionality suggestions, since I feel it is a necessary step towards that.

@Alejandro Jakubi That is mostly not applicable in this example, as the components are only used for output and their states/values never needed for computation.

If you object so much to using components, on such general grounds, then you ought to make a post or SCR about it. Mentioning such a very general objection to a very particular solution is, in my opinion, off topic. It is like objecting fundamentally to the internal formats of implicit plot structures just because someone suggested using them to solve some simple example. Your objections are not wrong, but they are so very general that they misplaced here.

@Alejandro Jakubi That is mostly not applicable in this example, as the components are only used for output and their states/values never needed for computation.

If you object so much to using components, on such general grounds, then you ought to make a post or SCR about it. Mentioning such a very general objection to a very particular solution is, in my opinion, off topic. It is like objecting fundamentally to the internal formats of implicit plot structures just because someone suggested using them to solve some simple example. Your objections are not wrong, but they are so very general that they misplaced here.

@Axel Vogt I agree with Axel.

@Axel Vogt I agree with Axel.

@sabyadg For Maple 15 you could try Preben's routine for resizing all plots in a saved worksheet file, or commands to presize the plot upon insertion. The mechanism for the latter could be improved, but neither would be a perfect solution for exactly what you've described.

There are hints that it might be done more easily, and closer to what you've described, in Maple 17. But I would really like to see a proper user-friendly solution built into the next release of Maple.