For various values of t1 there will be more than a single real value for t2 as roots of mrdot0. The Asker may wish to consider whether it matters which value of t2 is taken.

If it matters which value of t2 is accepted then either fsolve's `avoid` option could be used alongwise repeated fsolve calls, or RootFinding:-NextZero might be used with judicious use of the starting value (based on the previous t1's accepted t2 value?) and `maxdistance` option (based on t1?).

Or you could take the `min`, say, of multiple results from `solve`. (...which does what? Call evalf/RootOf repeatedly using fsolve & avoid? It might be faster to use NextZero, using unapply just once of course.)

Also (implied in Carl's Answer) the first call to `solve` for mrdot0 would need to be brought inside the t1-loop for it to be changed to a numeric fsolve (or NextZero) call, so that t1 had a numeric value each time it was computed.

acer

Carl, you wrote, "It is necessary to assume that they are positive."

What if `A` and `B` are of opposite sign, or one them is zero, or both of them are negative with `a` an integer?

acer

Carl, you wrote, "It is necessary to assume that they are positive."

What if `A` and `B` are of opposite sign, or one them is zero, or both of them are negative with `a` an integer?

acer

Have you considered upgrading to Maple 7 (2001) or later?

acer

@Doug Meade I'm not sure if my earlier message was clear (and apologies if you understood this already), but you followed-up with, "An alert that alerts users to possibly unexpected consequences to what should be protected names should also be flagged." However this example with the imaginary unit has nothing to do with protected names.

If `Calculator` were a protected name then the imaginary unit issue that you've observed would still occur.

I know of a somewhat similar situation from a few years back. The module for the Maple-Nag Connector is in a .mla archive which was license-locked (by Maple) back when that was a toolbox add-on that was sold separately from Maple. Here's the kind of thing that would happen: Call `LUDecomposition` with its output=NAG option, trigger the scan and read of the name `NAG` from .mla archives in libname merely on account of that reference, for whatever reason fail the license check in the ModuleLoad of the NAG module, then get an error message from that ModuleLoad, and then the ModuleLoad would (unassign) clobber the module name by NAG:='NAG', after which any subsequent similar calls to LUDecomposition & friends would work fine.

The same mechanism was in the ModuleLoad of the some other add-on modules (BlockBuilder maybe?). But that name wasn't already in use as a keyword option to popular LinearAlgbebra commands.

Back to the main line: there are a few other schemes that could ensure that the Calculator switched the imaginary unit for its own use while avoiding doing so via its ModuleLoad. They're just less slick. For example the routines in the rest of the Calculator could instead check a semaphore (module local, as a flag) and, if not yet set, adjust the imaginary unit and set the local. That is, adjust state when the module is first used rather than when it is first loaded/referenced.

Some ModuleLoad actions seem OK. The packages which use ModuleLoad to do define_external calls (and reassign some of their dummy exports to be call_externals) appear reasonable. But changing global state and behaviour seems dodgy.

Here's another kind of use that I find awkward,

showstat(ImageTools::ModuleLoad);

ImageTools:-ModuleLoad := proc()
   1   TypeTools:-AddType('Image',op(ImageTools:-IsImage));
   2   TypeTools:-AddType('GrayImage',op(ImageTools:-IsGrayImage));
   3   TypeTools:-AddType('ColorImage',op(ImageTools:-IsColorImage));
   4   TypeTools:-AddType('ColorAImage',op(ImageTools:-IsColorAImage));
   5   NULL
end proc

eval(ImageTools:-IsImage);
Error, IsImage is not a command in the ImageTools package

How can one utilize those type-checks without reading the ImageTools module from archive? I mean loading the module name from .mla archive, not rebinding exports' names via `with`. The `IsImage` routine is not an export of the package. Suppose one wished to test in a procedure that an Array would be recognized as an "image". The procedure is not the right place to call `with`. So how to get the types added, in a noninteractive session? It's awkward.

In recent Maple there is less need for `AddType` used in that way, since objects might carry around with them the neceesary means to check their own type or to dispatch. But I haven't seen a great deal of revising so far, where the structures of older packages get re-coded as objects.

I believe that the ModuleLoad of the module will be called when the name is first read from Library archive, which should happen when it is first referenced. Ie. it's not relevant whether one attempts to assign to the name `Calculator` -- just using it is enough.

A quick test in Maple 17.00 confirms this.

restart:

interface(imaginaryunit);

                               I

Calculator:

interface(imaginaryunit);

                               i

This is an example of how using ModuleLoad in a way that is not super careful can run amok with the global namespace (which modules were designed to help with!).

acer

I suspect that a significant part of the performance may relate to whether the rhs b[i] are only ever stored in a Matrix, as opposed to being all separate (Vectors, say).

I would not expect a huge amount of performance improvement because the float[8] machinery for LinearAlgebra:-Modular should already use fast simd/threaded/cache-tuned BLAS where possible, even when run in regular (serial programming) mode from Maple.

I didn't check... but it's even possible that the define_external calls from the LinearAlgebra:-Modular Library routines do not use the THREAD_SAFE option -- in which case the ensuing call_externals would be mutually blocking.

There may be a bit of overhead costs to save, and a tiny bit more threading to eke out. Some of that may just be due to being consistent with a storage order (column-major, -minor), or other seemingly minor aspects.

Here's a version of Carl's sheet, trying also to use the Task threading model to parallelize.

acer

I suspect that a significant part of the performance may relate to whether the rhs b[i] are only ever stored in a Matrix, as opposed to being all separate (Vectors, say).

I would not expect a huge amount of performance improvement because the float[8] machinery for LinearAlgebra:-Modular should already use fast simd/threaded/cache-tuned BLAS where possible, even when run in regular (serial programming) mode from Maple.

I didn't check... but it's even possible that the define_external calls from the LinearAlgebra:-Modular Library routines do not use the THREAD_SAFE option -- in which case the ensuing call_externals would be mutually blocking.

There may be a bit of overhead costs to save, and a tiny bit more threading to eke out. Some of that may just be due to being consistent with a storage order (column-major, -minor), or other seemingly minor aspects.

Here's a version of Carl's sheet, trying also to use the Task threading model to parallelize.

acer

@Alejandro Jakubi Yes, I knew of that earlier thread here.

There's a difference between something announced and something appearing only in a a member's Question. The Maple Player is an important piece of missing functionality that could help make Maple more competitive. But it didn't get an announcement of its own. There was a big announcement for Mobius, at which point an earlier version of the Player could be downloaded from links available to those who signed up for the Mobius pilot.

But now the Player has a "product" page all its own, and is immediately downloadable.

FWIW, in addition to,

d := conjugate(u)*conjugate(y)+conjugate(v)*conjugate(x):
z := conjugate(f)/d+G*w*conjugate(w)*conjugate(y)/d:

simplify(z,size);                                        
                                      _ _   _
                                  G w w y + f
                                  -----------
                                   _ _   _ _
                                   u y + v x

there is also, for this example,

normal(z);
                                      _ _   _
                                  G w w y + f
                                  -----------
                                   _ _   _ _
                                   u y + v x

combine(%);
                                 _____       _
                                 (w y) G w + f
                                 -------------
                                  ___________
                                  (u y + v x)

I'm certainly not saying that these will handle all your examples. But for simplification it often serves to try other avenues, depending on how much the final form is important to you.

acer

@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.

@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?