@tomleslie It is not true what you wrote in the other thread, that the way with uses LA=LinearAlgebra; is incorrect. There are several valid ways of utilizing uses. The problem in the earlier thread was that neither valid way was being used for one call (to Transpose).

The problem(s) here are different. The while i<>j look like a problem(in at least understanding). Also the abs(x-p) should probably be LinearAlgebra:-Norm(x-p) or similar. I haven't considered further.

@sunflower You need that to be LinearAlgebra:-Transpose or LA:-Transpose (since for the latter you are already doing uses LA=LinearAlgebra.

I don't really understand why you are doing those LinearSolve calls on hard-coded b, but perhaps you intend to do something more general with it later on. You certainly don't need to print(x) if you are just going to return x.

What do you expect to happen if any of the L[i,i] are zero?

acer

@Carl Love It's possible that this too would produce the kinds of Matrix he's after. Eigenvalues will return purely real values in this case. Statistics:-Sample is fast enough that this might do (even if tweaks are required).

GUE:= proc(N::posint)
uses LA= LinearAlgebra, ST= Statistics;
local R,G1,G2,C,H;
     R:= ST:-Distribution(Normal(0,1));
     G1:= ST:-Sample(R, [N,N]);
     G2:= ST:-Sample(R, [N,N]);
     H:= Matrix(LA:-MatrixAdd(G1,G2,1,I),shape=hermitian);
     convert(LA:-Eigenvalues(H)/sqrt(4.0*N), list)[];
end proc:

Similalry for the second curve,

Download flat2.mw

@Adri van der Meer In the Standard GUI one could also use the typeset symbol for arc-degrees.

sol:=dsolve({diff(y(x),x,x)+y(x)=0,y(0)=0,D(y)(0)=0.5},numeric):

plots:-odeplot(sol, x=0..10,
               tickmarks=[[seq(i*Pi/2=(i*180/2*`°`),i=1..8)],default]);

@ecterrab The new version is nicer, thanks.

The code inlined in your earlier Comment, now revised and updated, no longer shows the earlier assignment to `print/+`. You might wish to consider adding that print extension as before, so that some behaviour related to automatic simplification appears prettyprinted as before.

restart:

__fixplus:=module() option package; export `+`; end module:

`print/+`:=eval(:-`+`):

with(__fixplus):

macro(__fixplus:-`+`=:-`+`):

'1/2*(x+y)';

                                  1     1  
                                  - x + - y
                                  2     2  

Note that automatic simplification did not occur above. It merely seemed to, due to the printing mechanism.

lprint(eval(%,1));
  (1/2)*(x+y)

The case of procedure bodies is improved over before, to be sure. It's not exactly the same now as in stock Maple, though. Calls to infix `+` in the proc body are now calls to prefix :-`+`. And here too without automatic simplification.

proc(a,b) 1/2*(a+b); end proc;

                     proc(a, b) 1/2*:-`+`(a, b) end proc;

This is an interesting way to disable a class of automatic simplifications.

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