Can you let us know what you were intending to do?  It looks like you may have been intending to replace the zeroes in a container called Butcher with the empty symbol ``.

That can be achieved with this, which is only slightly different than your code:

Butcher := [0, "test", 34, y^2, 0]:
Butcher := map( x->if x=0 then `` else x end if, Butcher );

Alternatively, perhaps you were simply trying to remove all the zero elements from your container. You can do that with remove:

Butcher := [0, "test", 34, y^2, 0]:
Butcher := remove( verify, Butcher, 0 );

I assume by "Convert to hermit matrix" you mean you're taking the Hermitian transpose of a.
Following is a very simple class of matrices fulfilling your criterion, where λ is an arbitrary complex scalar. I'll leave it to you to determine whether any others exist.

with(LinearAlgebra):
n := 4:
a := lambda * IdentityMatrix(n,n);

b := HermitianTranspose(a);

simplify( Norm( MatrixMatrixMultiply(b, a), 2 ) - Norm(a, 2)^2 );

@Ratch Since no one said so explicitly in their excellent responses, it's worth mentioning for the benefit of future readers that solve attempts exact solutions to your problem, while fsolve provides approximate solutions using floating-point arithmetic.

You can control the precision of fsolve's approximation using the Digits environment variable.  Note that for general equations or systems, it will return at most a single real root.

 

I'm afraid I don't know what you're looking for, can you rephrase the question?

If we try to solve the equation  in Maple, we see that indeed the only solutions are a=b and a=-b.  Is your equation somehow more general than that?

> eqn := 3*a^2 - 3*b^2 = 0:
> solve( eqn, [a] );
                      [[a = b], [a = -b]]

@JacquesC This is a rather late reply, having just found this thread.  In any case, a copy of my thesis has been online at my still-extant McMaster user page since its publication:

Property Inference for Maple: An Application of Abstract Interpretation

@Adri van der Meer To expand on Adri's answer, you can combine this technique usefully with the unapply command to generate a procedure you can plot or sample with:

pointlist := [[0,2],[3,-2],[7,6],[9,5]]:
p := unapply( CurveFitting:-Spline(pointlist, _x, degree=1), _x):
plot( p, 0..9 );

Lastly, as a demonstration of the ease with which Maple's compiler can be used for tasks like this, it is possible to generate a procedure (below called pc) which can be used for rapidly sampling of the data points:

pointlist := [[0,2],[3,-2],[7,6],[9,5]]:
p := unapply( CurveFitting:-Spline( evalf(pointlist), _x, degree=1 ), _x):
pc := Compiler:-Compile( codegen[prep2trans]( eval(p) ) );
plot( pc, 0..9 );

[EDIT: as acer correctly notes, the second approach I describe above, while simple, does not scale beyond a certain size and it is better to make use of the efficient numerical interpolation techniques found in CurveFitting[ArrayInterpolation] instead.]

Hope that helps.

@Dira Since you have one solution already, you may be interested in another using the nextprime command:

n := 999:
while n <= 1015 do n := nextprime(n); end do;

@Carl Love Just to qualify Carl's answer slightly, his definition requires you to have the LinearAlgebra package already loaded by having executed 'with(LinearAlgebra);'.

To get the same thing whether or not LinearAlgebra has been loaded, you can just insert the LinearAlgebra qualifier, e.g.

f := unapply(LinearAlgebra:-Trace(M), x);

I actually gave a short talk on how to regard Maple as a theorem prover for a course on automated theorem proof I took this past autumn: here are the slides. As DJKeenan said, the closest thing to an automated theorem prover today in Maple is is and the assume facility. But this tool was never intended for serious use as a theorem prover, and can't really be compared to any theorem provers available today. For one thing, it doesn't have any way of expressing set membership or existential or universal quantification. A theorem prover would be a nice asset in Maple, or with any computer algebra system. (Indeed, the MathScheme project at my university has a combined CAS/theorem prover as its goal.) There are a few obstacles to be overcome prior to the inclusion of a theorem prover in Maple: 1. Consistency of representation. Different Maple packages date from different eras in Maple's evolution, and the representation of mathematical objects is not always consistent: in many cases, these distinct representations are maintained out of an understandable desire for backwards compatibility. I would expect a proof language to require more consistency from the language. One way of avoiding this initially is to start with a restricted subset of Maple for which the representation of data is fairly consistent. 2. A robust type system. Maple is an untyped language. It does have a type system which is very useful for making certain structural distinctions, but there are many things which cannot be distinguished by the checks the type system currently allows. A proof system will need to have all kinds of predicates about the objects concerned, many of which would be best expressed as types. 3. A means of indicating theories. There is a massive amount of ower and sophistication within Maple's library packages, but no consistent mechanism for indicating the underlying theory upon which a particular algorithm is based and how this theory may relate to other theories. Programmers and advanced users of Maple know which particular invocations of commands may be used together. They know that symbols in expressions passed to evalc are understood to be reals, while in other contexts these symbols are taken to be complex numbers. They know that LinearAlgebra is based on, well, linear algebra, while limit is based on calculus. However, an automated theorem prover will requires this human knowledge to be systematized and justified. Indeed, it's highly probable that much of the expressive power of Maple depends on the combination of packages with different underlying theories to positive effect. Some packages may be even based on more advanced mathematics than their authors intended or realized. Thinking deeply about how the underlying theories do relate may produce some very interesting revelations, and maybe even new mathematical knowledge! On the other hand, "borderline" cases involving the combinations of different theories may well be responsible for outstanding bugs in this and other CASes, so some deep thought here might help fix bugs too.

Well, whether or not the implementation of combinat[choose] is optimal is somewhat beside the point. By definition, it takes list of size n and returns a list of size n choose k. Using it requires computing all combinations and returning them in a data structure immediately. This requires the immediate consumption of a lot of memory, which in typical cases is probably not going to be used for quite some time. In some languages, this could be avoided by using lazy evaluation: the command returns the shell of a list, but any given element is not computed until the code asks for it. Another method, which would be possible in Maple, is to use a iterator which, when invoked, returns the next combination. The combinat package currently offers this for partitions with the commands combinat[firstpart], combinat[nextpart] and associated commands, but it does not offer this functionality for combinations.

Well, whether or not the implementation of combinat[choose] is optimal is somewhat beside the point. By definition, it takes list of size n and returns a list of size n choose k. Using it requires computing all combinations and returning them in a data structure immediately. This requires the immediate consumption of a lot of memory, which in typical cases is probably not going to be used for quite some time. In some languages, this could be avoided by using lazy evaluation: the command returns the shell of a list, but any given element is not computed until the code asks for it. Another method, which would be possible in Maple, is to use a iterator which, when invoked, returns the next combination. The combinat package currently offers this for partitions with the commands combinat[firstpart], combinat[nextpart] and associated commands, but it does not offer this functionality for combinations.

I was a bit surprised to see I am only three countries away from "world traveller" status. I think perhaps the bar should be set a bit higher, since in some parts of world it's exceedingly easy to have been in more than ten countries. For example, until 2003, I had only ever been to Canada, the U.S., and Mexico. On my first European trip, I took the train from Rome (where I also visited the Vatican) to Nice, which went through Monaco. So I got to tack on four countries with quite little effort. I suppose this leads to another question, something like the travelling salesman's problem. What countries should one visit, and what path should one follow, to acquire "world traveller" status most easily?

I entirely understand the desire to improve whattype, and it can be useful tool for people beginning to learn about Maple's type system. But is is dangerous. Few people coming to Maple have seen a programming language with subtyping before, and so they are used to thinking of objects as having a single type. 'whattype' is just useful enough to lull them into complacency here, and I've seen a lot of user code using it which is buggy or just inefficient (because it does a whole lot of useless type checks). Consider p := proc(x) if whattype(x)='table' then true else false; end if; end proc: q := proc(x) if type(x, 'table') then true else false; end if; end proc: Now, p(table()) and q(table()) return true, as they ought to. But p(array([1,2])) is false, even though an array is also a table (as q(array([1,2])) reports). On top of that, looking at the code for whattype, we had to do 20 type checks to get a result on the inputs above, whereas with 'type' we needed just one. Type-checking should be done against a specific type with type(e, t), full stop.

Very impressive. I threw in the keyword of a little Perl script I wrote several years ago and is available from my website only as a tarball. Not only did the search engine find it, it also managed to tell me what license I had distributed it under. I wonder if we'll see a rise in online code libraries in future?

Another idea which is perhaps a bit more generalizable would be to use Maple's ToInert routine to convert the procedure to an inert form; this is essentially an abstract syntax tree representation of the procedure in question. This could then be recursively traversed and printed in some specified way with printf or sprintf. One benefit would be that they could even be printed out to a file or other program.