I submitted a bug report.

acer

@Axel Vogt I suppose that it's possible that both these hold:

1) the set on the real line has been supplied from elsewhere, as some combination of RealRange calls.

2) there is a need for efficiency

in which case conversion might be possible at the time of creation of the procedure. Eg,

restart:

f := subs( r=eval(convert(Or(a::RealRange(0,Open(1)),
                             a::RealRange(2,3)),relation),
                  [And=`and`,Or=`or`]),
      proc(a)
        if r then a; else no; end if;
      end proc );

            f := proc(a)
               if 0 <= a and a < 1 or 2 <= a and a <= 3 then a else no end if
            end proc

f(-5), f(0.5), f(1.5), f(2.5), f(7.5);

                                  no, 0.5, no, 2.5, no

But in the absence of a great need for efficiency I might just choose to use is.

@John Dolese Yes, a ColorTools:-Color object cannot be prettyprinted in a TextArea embedded component. That kind of component is for string representation, as plaintext. In contrast, the colorful output you show (as the usual 2D Math output's display of a ColorTools:-Color object) is typset.

You also cannot get such an object to be properly displayed as if it were typeset, in MathContainer. There are quite a lot of things which don't get prettyprinted properly in MathContainers.

I suggest you try another approach, to show the changing color generated via the Slider.

• You could use the color to shade a plot.
• Or you could use it to make an image (in the ImageTools sense) that you put on a Label component.

There is an example of the latter, albeit in the result of a call to the Explore command, as the RGB example here. There is an example of dynamically pushing an image (float[8] Array) onto a Label component in the pushimage procedure in the Startup Code of the ArgumentShading MathApp. This seems overly complicated for displaying just a single color.

Here is a very simpleminded example of the former, using a plot. The action code behind each Slider is identical. (Personally I find it easier to put only calls to a single procedure behind components, and have that procedure be defined elsewhere so that I can call it manually and debug, edit it centrally, etc. But that's a matter of personal coding style.) Of course you can move all these components into a Table, etc. And of course you could use plots:-display to combine a whole slew of plots with such differently colored thick lines.

simplecolor.mw

If you're just using RGB values then you don't need to call ColorTools:-Color to get that triple into a plot. The first of these below would do (and might be slightly more efficient). But given your prior Posts about color spaces I figured you want to be able to do things like the second of these below. Of course using a thick solid line is just one way to get a single shaded area in a plot.

Download simplecolorB.mw

@dorna01 You wrote,

"...and n=0,1,2.

Except of omega and k ,other parameters is canstant."

So what is the value of each of K? Is it the same as that of c?

M[2,6] contains a function call to BesselN. Did you mean BesselJ or BesselY or such, instead?

If I right-click on the Output in Mathematica 10.1 and use "Convert To" to get "InputForm" then I can copy and paste the following string:

(-(1/R^6))*2*I*((2*Pi*R^3*(k1^2*R^2 + 2*k1*k2*R^2 + k2^2*R^2 - 30)*
           BesselJ[3, R*Abs[k1 + k2]])/Abs[k1 + k2]^3 + 
      (10*Pi*R^4*BesselJ[2, R*Abs[k1 + k2]])/(k1 + k2)^2 - 
      (1/(k1 + k2)^4)*(8*
      R^2*(R*(k1 + k2)*(k1^2*R^2 + 2*k1*k2*R^2 + k2^2*R^2 - 6)*
                Cos[R*(k1 + k2)] - 
        3*(k1^2*R^2 + 2*k1*k2*R^2 + k2^2*R^2 - 2)*
                Sin[R*(k1 + k2)])) + (1/(k1 + k2)^6)*
        (8*(R*(k1 + k2)*(k1^4*R^4 + 4*k1^3*k2*R^4 + 
           k1^2*(6*k2^2*R^4 - 20*R^2) + 
                   4*k1*k2*R^2*(k2^2*R^2 - 10) + k2^4*R^4 - 
           20*k2^2*R^2 + 120)*
                Cos[R*(k1 + k2)] - 5*(k1^4*R^4 + 4*k1^3*k2*R^4 + 
                   6*k1^2*R^2*(k2^2*R^2 - 2) + 
           4*k1*k2*R^2*(k2^2*R^2 - 6) + k2^4*R^4 - 
                   12*k2^2*R^2 + 24)*Sin[R*(k1 + k2)])) + 
      (R^4*(R*(k1 + k2)*Cos[R*(k1 + k2)] - Sin[R*(k1 + k2)]))/(k1 + 
       k2)^2)

Note that the instance of "\[Pi]" from the copy/pasted default output are now just "Pi". And the Maple command MmaTranslator:-FromMma then translates it correctly.

I evaluate that result in Mathematica 10.1 at the point k1=2,k2=1,R=6 to floating-point using N[] then I get 0. - 0.237918*I. That agrees with NIntegrate[] as well as Maple's evalf(Int(...)) on the original problem with those parameter values. And it also agrees with the result of applying evalf to the translation of the above input, evaluated at those parameter values.

The help page for FromMma says that it will, "convert Mathematica input into equivalent Maple input". Since a pasted string by itself doesn't contain the information about whether it was copied from Mathematica as (one of several  possible) output forms or as input form then it seems reasonable to think that InputForm should be used. The FromMma help page uses the term "Mathematica input" a great deal, but perhaps a requirement for Mathematica's InputForm should be stated explicitly.

I get the same error if I try to enter a similar typeset piecewise in 2D Input mode using either the Expression palette or command-completion on the typed partial input piecewise . I see that whether I enclose the whole operator in delimiting brackets or if I explicitly type it as proc(t)... end proc.

So if that's what you were attempting then I'd say that yes, it's a bug.

acer

@Carl Love See here and here.

@sunflower Whether you want to type in the whole procedure line by line, or whether you want to paste it in, the important thing is that you don't input the Enter key alone, until you have input the end proc line.

Instead, after you have finished inputing each line, input the keystrokes Shift-Enter together, to move the input cursor down to the next line.

The Enter key will evaluate what you've typed so far in that section. The Shift-Enter combination will advance to the next line without evaluating. If you make Maple evaluate before you've completed inputing the whole procedure then you'll get an error message.

@Carl Love Yes, I meant Shift-Enter. Thanks Carl. I've corrected it.

@sunflower You need to put all the lines of code for the procedure into a single Execution Group or a single Paragraph.

By that I mean all the lines between and including the frame:= proc(n) and the end proc lines.

Do not hit the Enter (or Return) key between those lines of code. If you want to paste then in line by line then use the combined keystrokes Shift-Enter to advance to a new line. Or copy and paste the whole set of procedure lines at once.

If you mistakenly press the Enter key after only typing the frame:= proc(n) code then you'll get that error, because Maple will try to execute an incomplete procedure code body. It appears like you may be doing this.

@Lulu That example produces that error for me in Maple 2015.1 using 64bit Maple for Windows 7, with Digits set to 19 or higher (as far as can tell), but succeeds for Digits set to 18 down to 10 (all in fresh sessions).

I will submit a bug report.

@Lulu Digits is an enviroment variable that fsolve adjusts internally so as to increase the working precision in order to attain the desired accuracy.

Since it's an environment variable the changes made to Digits inside fsolve are not apparent when fsolve is left and control returns to the higher level.

Sometimes a badly conditioned example can foil fsolve's methodology. For example, `fsolve/polyill` can try repeated Digits-doubling in order to overcome numerical difficulties. But when that does not succeed then the maximal Digits value gets hit. It's also possible that some individual subcomputation which tries to determine by how much to increase Digits goes wrong and generates an invalid value (too high). These bugs are rare, but they can happen.

Having an example is useful, for debugging and for checking whether the problem persists in later versions.

@MDD Do you need to create them all up front, before you work on them? Do you care about memory allocation, or just about raw speed?

Do you really need them to be lists? Or would Vectors work?

If Vectors are ok, then would it be ok if you could create then in clumps (but not all at once), and then access them by indexing both by row and along a column?

The question about getting the most efficient way can depend on how you intend on using them.

Are you trying to say that you want to reflect the plot across the y-axis? eg,

P := plot( A, x0=-3..5 ):

plots:-display( P, plottools:-reflect(P, [[0,0],[0,1]]) );

acer

@Harry Garst 

Your second example of plot(0^(x^2), x=-3..3) may appear wholly flat because the point x=0 is not necessarily used as a data point by `plot`, and because your formula might run under evalhf mode.

But the following is somewhat related to my answer above, where the data points for x are explicitly specified. I used Maple 2015.1 below, but a similar effect was had in my Maple 18.02, both 64bit for Linux.

Download zeropow.mw