The line means that h(x,a) = BesselJ(1,a*x) is annihilated by the operator x*D_x - a*D_a. I believe that the system you give is in the ideal generated by the system they present, but not the other way around. In other words, your system is missing some relations.

The line means that h(x,a) = BesselJ(1,a*x) is annihilated by the operator x*D_x - a*D_a. I believe that the system you give is in the ideal generated by the system they present, but not the other way around. In other words, your system is missing some relations.

Actually, isprime not ``probabilistic'' at all. It uses a series of tests, all quite deterministic, which are conjectured (by number theorists who ought to know this stuff) to be complete, but no one knows for sure. Unless things have been changed in Maple 11 that is. testeq, on the other hand, is probabilitic, however it is implemented in a deterministic way. In theory, testeq's chance of failure could be made lower than the chance of a cosmic ray interfering with your CPU, but in practice testeq is not quite that zealous.

Actually, isprime not ``probabilistic'' at all. It uses a series of tests, all quite deterministic, which are conjectured (by number theorists who ought to know this stuff) to be complete, but no one knows for sure. Unless things have been changed in Maple 11 that is. testeq, on the other hand, is probabilitic, however it is implemented in a deterministic way. In theory, testeq's chance of failure could be made lower than the chance of a cosmic ray interfering with your CPU, but in practice testeq is not quite that zealous.

Yeah, I apparently post too much if I am approaching 700. And you should trust my experience, not my judgement! I tend to work by 'plowing ahead', and I don't mind if once in a while I have to backtrack because I've learned something new. Even when I do not have sufficient experience in a topic, I still draw conclusions, and they can be quite wrong. As I have written in another posting, I am quite happy when people question my reasoning, it keeps me on my toes.

Yeah, I apparently post too much if I am approaching 700. And you should trust my experience, not my judgement! I tend to work by 'plowing ahead', and I don't mind if once in a while I have to backtrack because I've learned something new. Even when I do not have sufficient experience in a topic, I still draw conclusions, and they can be quite wrong. As I have written in another posting, I am quite happy when people question my reasoning, it keeps me on my toes.

My post is as good an explanation as I can cobble together, however it does not satisfy me that this is a good name! Some years ago, I probably would have suggested makeproc as a better name. Now, I would probably prefer functionof (or even FunctionOf).

My post is as good an explanation as I can cobble together, however it does not satisfy me that this is a good name! Some years ago, I probably would have suggested makeproc as a better name. Now, I would probably prefer functionof (or even FunctionOf).

In the lambda calculus, a construction 't1 t2' (sometime written at t1(t2) ) where t1 and t2 are arbitrary terms is known as an 'application'. When t1 is a function, then 'evaluation' is also known as beta-reduction. Let f = lambda z. g(z,5). [in Maple that would be f := z -> g(z,5) ]. Then f x (in Maple f(x) is an application, which beta-reduces to g(x,5). What if you have g(x,5) and you want to get f above? In other words, you want to 'undo' the application (ie unapply)? Well, you ``abstract out'' the x, so you do h := unapply(g(x,5),x). And lo and behold, you get something back which is isomorphic to f above. Two points where this might be confusing: 1) Maple sometimes does eta-reduction, so that x->k(x) is 'the same as' k. 2) x+y might not look like an application, but it "really" is `+`(x,y). Any book on the lambda-calculus should cover this, and would help you understand where some of this is coming from.

In the lambda calculus, a construction 't1 t2' (sometime written at t1(t2) ) where t1 and t2 are arbitrary terms is known as an 'application'. When t1 is a function, then 'evaluation' is also known as beta-reduction. Let f = lambda z. g(z,5). [in Maple that would be f := z -> g(z,5) ]. Then f x (in Maple f(x) is an application, which beta-reduces to g(x,5). What if you have g(x,5) and you want to get f above? In other words, you want to 'undo' the application (ie unapply)? Well, you ``abstract out'' the x, so you do h := unapply(g(x,5),x). And lo and behold, you get something back which is isomorphic to f above. Two points where this might be confusing: 1) Maple sometimes does eta-reduction, so that x->k(x) is 'the same as' k. 2) x+y might not look like an application, but it "really" is `+`(x,y). Any book on the lambda-calculus should cover this, and would help you understand where some of this is coming from.

Yes, that's what he means. More specifically, he was pointing you to the 'LinearAlgebra[Map]' function. The command-driven way of accessing help (much faster than pointy-clicky means) is to type

?Map

just like that at a Maple prompt.

Yes, that's what he means. More specifically, he was pointing you to the 'LinearAlgebra[Map]' function. The command-driven way of accessing help (much faster than pointy-clicky means) is to type

?Map

just like that at a Maple prompt.

I really meant when you have an unevaluated int, that you can fully inertize it. Value does indeed increase entropy.

I really meant when you have an unevaluated int, that you can fully inertize it. Value does indeed increase entropy.

I believe (but I do not know for sure) that this is related to the new argument processing functionality. It does seem like an odd ``feature'' though.