Consider the following four-dimensional matrix of four-dimensional matrices (they are the generators of the vector representation of the Lorentz group):

metric := Matrix(4,4,Vector([-1,1,1,1]),shape=diagonal):
generators := Matrix(4,4,
	(a,b) -> metric . Matrix(4,4,
	(c,d) -> metric[a,c]*metric[b,d] - metric[b,c]*metric[a,d])
);

The expression is antisymmetric in the indices a and b, i.e., the (outer) matrix is antisymmetric. So, to optimize my code (especially important, I suppose, when going to higher spacetime dimensions) I thought I would try adding the option shape=antisymmetric:

I am trying to use the EllipticE and EllipticF functions in an expression. The proper function call is EllipticE(z, k) where z = algebraic expression (the sine of the amplitude) k = algebraic expression (the parameter) I get exact agreement for 0 <>< value="" value=""><><>

I'm a relatively new user of Maple, and I use it to teach high school mathematics. I've noticed that when Maple expands an expression like (x+y+z)^6, the terms come out in a different order each time the operation is done. If 6 students do it on 6 computers we get 6 different orderings. Is there an explanation for why Maple's algorithm does this that would be potentially comprehensible to my students (they are quite curious)?

When I use the GUI to produce the graph of y = 5x^2/(1+x^2), the graph is cut off in the exported .eps. Precisely, Type In: 5x^2/(1+x^2) , Right click- plots-2D plot, then Right-Click on graph, export as .eps. Open the resulting .eps file and the graph is truncated at around x=3. ?(Exporting as .gif or .jpeg seems to work here). However, plot( 5x^2/(1+x^2), x=-10..10) produces the correct result upon .eps exportation I thought this might have with smartplot vs. plot, but 2D plots constructed with plot builder are truncated as well.

Just wondering... what's wrong with the following command? > plot( cot(x), x=-Pi..Pi, view=[-Pi..Pi,-3..3] ); -- Regards, Franky.

i need to solve a set of linear equations of size 7000x7000 using 128 digits, the system is sparsed. which of the "options" in LinearAlgebra[LinearSolve) is the the most efficient? is there more efficient builtin procedure for such computations? thank's

A new version of Plouffe's Inverter was announced by its author today in the usenet group comp.soft-sys.math.maple . That usenet posting gave this link to maple code for the inverter.

It also said this, "As usual, I would like to mention that this program is FREE and can be distributed at will, I just wish that the source is mentioned. Simon Plouffe"

Greetings. I have a question regarding the use of the Matrix Browser. I was experimenting with the Transpose function, trying to mimic the Matlab linear algebraic transpose. For a row Vector A, defined as: A=[0 1 2 3 4 5 6 7 ...] in Matlab A' will give me a column vector. 0 1 2 3 4 5 6 7 In Maple, ver. 11.02, using the Classic interface: >restart:with(LinearAlgebra): >A:=Vector[row]([0,1,2,3,4,5,6,7]); A := RTABLE(150962204,VECTOR([0, 1, 2, 3, 4, 5, 6, 7]),Vector[row]) >Transpose(A); RTABLE(151848540,MATRIX([[0], [1], [2], [3], [4], [5], [6], [7]]),Vector[column])

Can someone explain whether this is a bug or is Maple really splitting into 2 languages? In particular, for the input with(Logic); BooleanSimplify(Import(a < b and d = e and not a < bd)); in Maple's document mode or in the TTY version, quite different answers come back. I understand the [weird] reason why the TTY version returns 'false'. The question here is, why the difference?

Why maplenet error downloading?

Maple 11 generously introduced the option smooth=true to listdensityplot. But I am finding unexpected behavior with the option. In the code below, notice how the option smooth=true ends up triggering the transform "Scale" to produce a three-dimensional plot structure, but the option smooth=false, in conjunction with "Scale", produces (as expected) a two-dimensional plot structure. Code follows: with(plottools):with(plots): sample:=[seq([seq(i*j,i=1..40)],j=1..40)]: Grid:=listdensityplot(sample,smooth=true,colorstyle=HUE,style=patchnogrid); display(Grid); Scale:=transform((x,y)->[x*2*Pi/40,y*Pi/40]):

My Calculus III students stumbled on this buggy thing while evaluating a line integral to calculate the flux The curve [X(t),Y(t)] is the right-half of a Lemniscate with polar equation R^2=cos(2*theta). The vector field is F(x,y)=M(x,y)i+N(x,y)j. They were integrating M*dy-N*dx around the curve. If we let a=M*dy and aa=expand(M*dy), then they find that Maple's int gives inconsistent results. As far as I can tell, a and its twin aa are well-behaved over -Pi/4..Pi/4 and equal. Maybe it is a bug in how Maple handles elliptic integrals? Or maybe it is some issue with removable discontinuities?

I was writing a small procedure to generate random points on the unit sphere. The details are not directly relevant here, but the procedure was as follows.

randspherepts := proc(n::nonnegint, d::posint) 
 local i, p, r; 
 description "Returns co-ords of n random pts on the d-dimensional unit sphere [Knuth, 1998: sect. 3.4.1E]"; 
 uses ArrayTools;
 p:= Matrix(n, d, RandomTools:-Generate('distribution(Normal(0,1))', makeproc=true),datatype='hfloat',order='C_order');
 r:= ElementPower(AddAlongDimension(ElementPower(p,2),2),1/2);  
 seq(ElementDivide(p[i,1..-1],r[i]), i=1..n) 
end proc;

Can someone explain why is 0 handled differently by evalf[10] than nonzero numbers in the following examples? Digits:=50: epsilon:=Float(1.0,-30); -30 1.0 10 for x in [0,0.0,1,sqrt(2),Pi] do x,evalb(evalf[10](x)=evalf[10](x+epsilon)); od; 0, false 0., false 1, true (1/2) 2 , true Pi, true

In trying to answer the second question in How to determine the order of an ODE? I have unsuccessfully tried to use select to filter out the appropiate parts of the differential equations. In these attempts I have hit upon a behaviour of select I do not understand: In my opinion each of the following two code lines (or at the very least the second line) should return the differential expression itself:

select(has,diff(y(t),t),y);
select(has,diff(y(t),t),y(t));

But they do not; each line returns diff(y(t)), where the variable t with respect to which is being differentiated is missing. Why? Is it just me having fundamentally misunderstood something?