@vv My earlier point was that rebinding `+` will break worksheets and top-level code containing such instances of the name `+` in calls to convert and type specfunc and frontend, and that it's not been shown that there are not other ways that top-level code with break either.

Suppose you load the package which redefines `+`. And then you create a procedure proc(a,b) a+b; end proc. And then you save that in a .mla archive and redististribute it to someone else. It will then fail to work for them, since the procedure they have in the .mla is actually proc(a, b) M:-`+`(a, b) end proc. In other for this to work the original would have to be written as proc(a,b) :-`+`(a,b); end proc. So not only would the example need to be fixed by editing, but it would be onerous to write all sums like that.

So it's not just that convert(...,`+`) would break, at the top level.

It was not difficult to think of these examples. It's the examples that I have not yet imagined that worry me more.

@vv You've conflated two ideas. One idea (from Christopher2222) was to always load the Physics package up front. That will cause `*` to be rebound, and break examples like convert([1,2,3], `*`) until edited to use :-`*` instead.

Edgardo's suggestion was to use a module that rebound only `+`, and that does not affect your convert example involving `*`. It works as before.

I do not see loading Physics as fixing the problem, anyway. Note that Physics does not export `+`. I suspect that the original and some other examples succeed after loading Physics merely by some quirk. It does not appear to provide a general workaround. Consider,

restart:
with(Physics):

expr2:=x1+t2+t3+t4+t5+t6+t7+t8+t9+t10+t11+t12+t13+t14+t15+t16
       +t17+t18+t19+t20+t21+t22+y0-y0+t28;

     expr2 := t2 + t3 + t4 + t5 + t6 + t7 + t8 + t9 + t10 + t11 + t12 + t13 + t14

           + t15 + t16 + t17 + t18 + t19 + t20 + t21 + t22 + t28 + x1

expr2:=x1+t2+t3+t4+t5+t6+t7+t8+t9+t10+t11+t12+t13+t14+t15+t16
       +t17+t18+t19+t20+t21+t22+y0-y0+t28;

     expr2 := t2 + t3 + t4 + t5 + t6 + t7 + t8 + t9 + t10 + t11 + t12 + t13 + t14

           + t15 + t16 + t17 + t18 + t19 + t20 + t21 + t22 + t28 + x1 + t28 + x1

kernelopts(version);

           Maple 2015.0, X86 64 LINUX, Feb 17 2015, Build ID 1022128

@ecterrab Loading the suggested package module, as given, will break some existing top-level user code. [NB. The suggestion module has been subsequently revised, in the Comment above. I use the original M below.]

M:=module() export `+`; global `print/+`; option package;
    `+`:=()->:-`+`(args); `print/+`:=()->:-`+`(args);
   end module:
with(M):

convert([1,2,3],`+`);
Error, unrecognized conversion

So the top-level code would have to be edited to be like, say,

convert([1,2,3],:-`+`);
                               6

So, having rebound `+` in that way, one then has to be concerned about other purposes that the name `+` serves, and top-level instances of all such in one's code.

Here's another example.

frontend(expand, [sin(a+b)+cos(a+b)],
         [{`+`,`*`,'specfunc(anything,sin)'},{}]);
Error, type `+` does not exist

frontend(expand, [sin(a+b)+cos(a+b)],             
         [{:-`+`,`*`,'specfunc(anything,sin)'},{}]);

                  sin(a) cos(b) + cos(a) sin(b) + cos(a + b)

Sure that could be handled (without needing to search through and edit old code and worksheets) by also adding a type in the fix. But what other problems will there be? How does one know that all have been identified and corrected?

I will wait for the kernel update, to fix my Maple 2015.

Could one layer of function call be avoided, in this module? I mean, something like,

__fixplus:=module() option package; export `+`; `+`:=eval(:-`+`); end module:
`print/+`:=eval(:-`+`):
with(__fixplus):

For attempting these questions see Markiyan's answer (rsolve with option makeproc).

Readers interested in the Logistic map (in Maple) can find quite a bit of material via google. It's a popular topic.

Within Maple's Help system these two links are related:

IterativeMaps:-Bifurcation (and an older Mapleprimes post about the bifurcation diagram)

examples,Explore (the cobweb plot example, low down in the page)

@Preben Alsholm That's interesting. I don't quite see how the nature of A, T1, and AF would affect the running time, as those are merely containers for the computed results (eg, of the numeric integration).

On my Maple 18.02 on 64bit Linux the computation of the original worksheet blew up at the evalf(Int(...)) stage (resources) with NumSteps:=6 .

Download cotrule4.mw

@Alejandro Jakubi 

I am now seeing this,

restart;

solve({(1/(a-1)-1/(a+1))*(2*a^2-2)/a = 4/surd(2, 2), a <> 1, a <> -1});

                                /     (1/2)\ 
                               { a = 2      }
                                \          / 

kernelopts(version);

          Maple 2015.2, X86 64 LINUX, Nov 13 2015, Build ID 1087698

For the three examples shown above I see the bug in Maple 9.50 but not in Maple 9.03, on 32bit Linux.

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.