@Markiyan Hirnyk My answer here is different in that it uses a single call to `surfdata` which passes its supported optional arguments to specify the axes ranges. I believe that it address the question asked.

The Answer by marc005 does not use that simple functionality of `surfdata`, but rather produces a `surfdata` call and`plot3d` call (only the latter of which uses the specified axes ranges). Try it.

Robert Israel's suggestion in that same thread to which you've referred -- to use `subs` to replace ranges in the structure that results from calling `matrixplot` -- is more complicated. And it would run into trouble if the number of rows equalled the number of columns in the Matrix while the two desired target ranges differed from each other.

One aspect that you might want to clarify in this Question is the color space through which you hope to get from green to red. The particular shades that one gets in a color gradient -- between the given end-colors -- depends on the color space.

You might wish to have the shading gradient be in terms of HSV or RGB color spaces, for example. Those are prtty easy to handle since they are supported directly by the relevant plot coloring options. You could even have it graded in "Lab" or "XYZ" or other color spaces and then convert that back to RGB or HSV, and there is some support for that via the ColorTools package (although it's not so efficient to map the conversions provided there, over a large GRID or MESH in a 3D plot).

Carl's answer below is in terms of HSV. It's fits pretty well alongside the canned plot option 'shading=zhue' (which could well be why you mentioned, "from red to purple." Note that Carl's scheme is also varying the saturation and value (and you could choose to adjust that and keep those channels constant if you wish, or adjust to have them vary linearly from light green to dark red if your previous coloring function `C` did not do so).

The Post linked to in my answer below has examples of linear gradients in the RGB color space. Ie, you could get from light green to dark red by simply using linear (or other) mappings for each of those three channels. My linked post was also more about trying to grind out more efficiency in the process.

That raises the point that RGB is a color space related more to what devices emit than to what is visually perceived. A linear gradient of color in the "Lab" color space would appear as a more natural and even transition from green to red than would one in RGB. In RGB one goes through some unattractive muddy grayish shades to get from green to red, although that is not the case for all other pairs of end-colors. In "Lab" there is the tricky aspect that not all interpolated triples represent "displayable" shades that can be perceived. The visible spectrum is slightly concave in the Lab color space. So some regression back to the displayable spectrum may be necessary. This is a bit moot, however, without efficient conversion routines between RGB (or XYZ say) and Lab. I have to code for high efficiency production of RGB gradients that vary linearly in the channels of XYZ color space. I'm not sure whether it's very interesting to anyone else. I'm just waffling, here...

acer

@zpupster Are you looking for a plot of the two curves? Ie,

plot([cos(x),x]);

or,

plot([cos(x),x],x=0..Pi/2);

or similar?

@zpupster Are you looking for a plot of the two curves? Ie,

plot([cos(x),x]);

or,

plot([cos(x),x],x=0..Pi/2);

or similar?

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.