Those would all be weaknesses -- the 'specification' for prep2trans (informally) says that these things should be covered. I will try to submit a piece of code that gets around these limitations [it is quite easy to do].

Those would all be weaknesses -- the 'specification' for prep2trans (informally) says that these things should be covered. I will try to submit a piece of code that gets around these limitations [it is quite easy to do].

I believe that codegen[prep2trans] will automatically do what you want -- it is written to "prepare code to translate". It knows about a number of Maple constructs that can be ``expanded'' so that they can be translated to languages like C. If prep2trans does not work, write back, with ToInert/FromInert, it is just a few lines of code to translate a product to a for loop.

I believe that codegen[prep2trans] will automatically do what you want -- it is written to "prepare code to translate". It knows about a number of Maple constructs that can be ``expanded'' so that they can be translated to languages like C. If prep2trans does not work, write back, with ToInert/FromInert, it is just a few lines of code to translate a product to a for loop.

For the purposes of C code generation, I believe the generator will automatically convert things to float anyways [or at least, there are options to CodeGeneration[C] for that purpose], so 1/4 is fine. It really depends on what you are doing, and in fact, what your ultimate purpose is, what will be faster/slower. There are (usually) good reasons why some functions are faster/slower depending on whether the inputs are numeric or symbolic - but since the reasons can vary depending on the functionality, I can't give a blanket explanation. When I use Maple for code generation, the main task I perform with Maple is model-based manipulations, which are by far best done symbolically. Then since the eventual use is numeric, sometimes I convert to float before doing the actual code generation. For example, you can take a look at a Maple Conference 2005 paper for an example.

For the purposes of C code generation, I believe the generator will automatically convert things to float anyways [or at least, there are options to CodeGeneration[C] for that purpose], so 1/4 is fine. It really depends on what you are doing, and in fact, what your ultimate purpose is, what will be faster/slower. There are (usually) good reasons why some functions are faster/slower depending on whether the inputs are numeric or symbolic - but since the reasons can vary depending on the functionality, I can't give a blanket explanation. When I use Maple for code generation, the main task I perform with Maple is model-based manipulations, which are by far best done symbolically. Then since the eventual use is numeric, sometimes I convert to float before doing the actual code generation. For example, you can take a look at a Maple Conference 2005 paper for an example.

The basic difference is that in a piece of code, common sub-expressions (ie repeated computations) can be pulled out. And there is explicit code in codegen to do this (since in some cases it is very easy to do). This is not a fundamental difference between automatic differentiation and symbolic differentiation: if the Maple language had a let-in ``expression'', then these would be equivalent. Alas, Maple still does not have a let expression.

The basic difference is that in a piece of code, common sub-expressions (ie repeated computations) can be pulled out. And there is explicit code in codegen to do this (since in some cases it is very easy to do). This is not a fundamental difference between automatic differentiation and symbolic differentiation: if the Maple language had a let-in ``expression'', then these would be equivalent. Alas, Maple still does not have a let expression.

If you really need a reboot, then it sounds like a Java problem - the Maple kernel really does shut down properly, so that simply exiting should be sufficient. Have you tried your computations in Classic or the TTY version? It would be really useful to be able to pin down a little more closely which Maple component seems to be causing you all these problems.

If you really need a reboot, then it sounds like a Java problem - the Maple kernel really does shut down properly, so that simply exiting should be sufficient. Have you tried your computations in Classic or the TTY version? It would be really useful to be able to pin down a little more closely which Maple component seems to be causing you all these problems.

proc(p::procedure)     FromInert(eval(ToInert(p), _Inert_LOCALSEQ = proc() _Inert_LOCALSEQ(op(map(proc(mm) if mm::specfunc(anything,_Inert_DCOLON) then mm else _Inert_DCOLON(mm, _Inert_NAME("float",_Inert_ATTRIBUTE(_Inert_NAME("protected")))) end if end proc, [args]))) end)); end; should be right.

proc(p::procedure)     FromInert(eval(ToInert(p), _Inert_LOCALSEQ = proc() _Inert_LOCALSEQ(op(map(proc(mm) if mm::specfunc(anything,_Inert_DCOLON) then mm else _Inert_DCOLON(mm, _Inert_NAME("float",_Inert_ATTRIBUTE(_Inert_NAME("protected")))) end if end proc, [args]))) end)); end; should be right.

Is what I had in mind. However that seems to cause 'merely' a slowdown of a factor of 10. Could be that it is much worse on Windows XP though.

Is what I had in mind. However that seems to cause 'merely' a slowdown of a factor of 10. Could be that it is much worse on Windows XP though.

I wonder what kind of leaf it should be?