@awass 

kernelopts(version);

      Maple 17.00, X86 64 WINDOWS, Feb 21 2013, Build ID 813473

type(LinearAlgebra,`module`),type(LinearAlgebra,table);

                            true, false

type(combstruct,`module`),type(combstruct,table);

                            false, true

@awass 

kernelopts(version);

      Maple 17.00, X86 64 WINDOWS, Feb 21 2013, Build ID 813473

type(LinearAlgebra,`module`),type(LinearAlgebra,table);

                            true, false

type(combstruct,`module`),type(combstruct,table);

                            false, true

You should have,

uses LinearAlgebra;

instead of,

with(LinearAlgebra);

inside procedures such as Cons1 and Cons2.

Also, you should not need assumptions on the names. You are encountering premature evaluation of L(w1,w2,w3,w4,w5,w6,lam) which as first argument to NLPSolve is being mistakenly evaluated for symbolic (non-numeric) arguments w1,w2,...,lam.

Either have `L` return unevaluated for nonnumeric arguments, or guard with uneval quotes in that call to L, or use operator form for passing L and all the ranges to NLPSolve. If you do one of those, then you'll probably run up against NLPSolve's weak handling of gradient production for operator form, or need nicer ranges so that it doesn't trip up on the common infinity return value, etc. I haven't got NLPSolve to succeed here.

acer

How about lam=-0.33333333 or perhaps -1/3?

acer

How about lam=-0.33333333 or perhaps -1/3?

acer

@tiradentes The very last thing in my answer will not work in Maple 17. (You must not have tried it.) It was a suggestion for an alternative syntax for future Maple, that could remove the need for special evaluation rules on the first argument passed to `Explore`.

It omitted m[d] (incidentally, but which is not why it would not work) and could have been instead, with your prior assignments to mpg[mave] and mpg[ave]

Explore( plot,
            [ 7.28*m*( (1/mpg[mave]) - (1/mpg[ave]) ), m=0 .. 200000 ],
            parameters = [k=1/3000 .. 1/2000, mpgo = 40 .. 50, md = 150000..200000] );

Note that that last (syntax enhancement suggestion) splits the `plot` and its own arguments, the latter of which are passed in square brackets as a list. It is not the same as the completely explicit and direct call (which will work in Maple 17 but requires explicitly recopying the entire input, without any use of nested name assignments). Eg,

Explore( plot( 7.28*m*( (1/(mpgo - k*m/2 ) - (1/mpgo - k*md/2) ) ), m=0 .. 200000 ),
         parameters = [k=1/3000 .. 1/2000, mpgo = 40 .. 50, md = 150000..200000] );

@tiradentes The very last thing in my answer will not work in Maple 17. (You must not have tried it.) It was a suggestion for an alternative syntax for future Maple, that could remove the need for special evaluation rules on the first argument passed to `Explore`.

It omitted m[d] (incidentally, but which is not why it would not work) and could have been instead, with your prior assignments to mpg[mave] and mpg[ave]

Explore( plot,
            [ 7.28*m*( (1/mpg[mave]) - (1/mpg[ave]) ), m=0 .. 200000 ],
            parameters = [k=1/3000 .. 1/2000, mpgo = 40 .. 50, md = 150000..200000] );

Note that that last (syntax enhancement suggestion) splits the `plot` and its own arguments, the latter of which are passed in square brackets as a list. It is not the same as the completely explicit and direct call (which will work in Maple 17 but requires explicitly recopying the entire input, without any use of nested name assignments). Eg,

Explore( plot( 7.28*m*( (1/(mpgo - k*m/2 ) - (1/mpgo - k*md/2) ) ), m=0 .. 200000 ),
         parameters = [k=1/3000 .. 1/2000, mpgo = 40 .. 50, md = 150000..200000] );

Carl's answer is correct, of course.

But the numelems command, introduced in Maple 15, works for each of the indexable data structures list, set, Array, Vector, Matrix, table, and string. This command provides a somewhat more uniform way to query the number of elements of such structures than was possible in earlier versions.

note: A Record field might be queried with an indexed call, but `numelems` does not cover it, and a Record is not of type indexable.

acer

Carl's answer is correct, of course.

But the numelems command, introduced in Maple 15, works for each of the indexable data structures list, set, Array, Vector, Matrix, table, and string. This command provides a somewhat more uniform way to query the number of elements of such structures than was possible in earlier versions.

note: A Record field might be queried with an indexed call, but `numelems` does not cover it, and a Record is not of type indexable.

acer

How would using VBA rather than Maple help prevent your own mistakes here?

acer

The Asker happened to use a grayscale conversion, sure, but he particulaly wrote of wanting to plot "intensity levels" and did not write of wanting B&W per se.

In the absence of clarification it is somewhat dubious to try to deduce or state categorically that any of the distinct technical color space terms lightness, brightness, luminance, or intensity is what was being requested in particular. Lab, HSV, YUV, HSI... these are all amongst the possibilities. Sure, perceptual intensity might well be the front-runner.

It is possible that the OP is not aware of the differences, or does not consider that they matter much.

I chose V=value (brightness) of HSV mostly just because I happened to have the converted HSV structure alreadty at hand. I was trying to make suggestions about Components, mostly. I didn't even bother to optimize the code w.r.t. extraneous copies, fastest mapped operations, etc.

The Asker happened to use a grayscale conversion, sure, but he particulaly wrote of wanting to plot "intensity levels" and did not write of wanting B&W per se.

In the absence of clarification it is somewhat dubious to try to deduce or state categorically that any of the distinct technical color space terms lightness, brightness, luminance, or intensity is what was being requested in particular. Lab, HSV, YUV, HSI... these are all amongst the possibilities. Sure, perceptual intensity might well be the front-runner.

It is possible that the OP is not aware of the differences, or does not consider that they matter much.

I chose V=value (brightness) of HSV mostly just because I happened to have the converted HSV structure alreadty at hand. I was trying to make suggestions about Components, mostly. I didn't even bother to optimize the code w.r.t. extraneous copies, fastest mapped operations, etc.

I feel silly for not having noticed that the original exponent had 11 significant digits, so that naturally the behaviour at default Digits=10 is not as I wrote was expected. Carl has a sharp eye.

acer

I feel silly for not having noticed that the original exponent had 11 significant digits, so that naturally the behaviour at default Digits=10 is not as I wrote was expected. Carl has a sharp eye.

acer

@Christopher2222 Note that the hues appearing at the "bottom" (back) of your 3D plot get obscured by those on "top" (front).

Compare your original orientation=[0,0] with the scene you get viewing at orientation=[180,-180]. Viewed from the front then the purples are hidden. And so on, for most any angle. I don't know whether this effect is related to `symbolsize`.

Viewing instead the flat image from the H-layer replacement gets quite different behaviour in this regard.

ps. You likely ought not attempt style=patchnogrid unless the grid size is smaller.