That's a really nice use of ``.

Maple gets the antiderivative to this almost instantly. So why does the definite integral take several seconds, even if I specify method= ftoc?

That's a really nice use of ``.

Maple gets the antiderivative to this almost instantly. So why does the definite integral take several seconds, even if I specify method= ftoc?

@sunit Even if I replace your a0 and d by 0, I still get an error "Unable to convert to a first-order system". I don't know why. Hopefully someone else will take a look at it. I think that Preben Alsholm could solve it. After that problem is solved, I think that the conditions with a0 and d can be easily handled with piecewise.

I think that you need one more initial condition. You don't have any for a[2].

You'll need to give an explicit example of an expression that gives the error.

@sunit I editted it for you.

@Art Kalb Ah, I think that I understand your problem: I think that you have the mistaken impression that the behaviour of f(g(x)) can be controlled by a procedure named `f/g` for arbitrary f and g. The reality is that that mechanism only works for a few select system routines f, for example, evalf, print, type, value, diff.

@Art Kalb Ah, I think that I understand your problem: I think that you have the mistaken impression that the behaviour of f(g(x)) can be controlled by a procedure named `f/g` for arbitrary f and g. The reality is that that mechanism only works for a few select system routines f, for example, evalf, print, type, value, diff.

@Art Kalb What do you expect the code above to do? Show the command that you give and the output that you expect. What is name of the help file that you referred to, the one that you based this on?

@Art Kalb What do you expect the code above to do? Show the command that you give and the output that you expect. What is name of the help file that you referred to, the one that you based this on?

@Art Kalb You misinterpretted what I wrote. It is only in the places that you currently have unevaluation quotes that you need to change them to be both types of quotes. In summary

`f/g` is fine, it's just a name.

'f/g' is nonsense, unless you mean unevaluated division.

'`f/g`' is the unevaluated form of `f/g`.

`'f/g'` is just a name, albeit one likely to cause confusion.

I am absolutely 100% sure about this.

@Art Kalb You misinterpretted what I wrote. It is only in the places that you currently have unevaluation quotes that you need to change them to be both types of quotes. In summary

`f/g` is fine, it's just a name.

'f/g' is nonsense, unless you mean unevaluated division.

'`f/g`' is the unevaluated form of `f/g`.

`'f/g'` is just a name, albeit one likely to cause confusion.

I am absolutely 100% sure about this.

@Kitonum The default time command is showing the sum of the times on all processors. Parallel processing always takes more time, when time is measured that way, because there is significant overhead involved in dividing up the tasks among processors. The benefit of parallel processing, if any, is only evident when you look at the real time via time[real].

time[real](PP({$1..20}));
                             6.113
time[real](PowerSet({$1..20}));
                             4.302

You can also simply replace the seq in PP with Threads:-Seq. It turns out that there is not much benefit to the parallel processing here. But the benefit should increase as computers get more and more processors (I have 8). To make a better comparison, compare procedures where the only change is from seq to Threads:-Seq.

@Kitonum The default time command is showing the sum of the times on all processors. Parallel processing always takes more time, when time is measured that way, because there is significant overhead involved in dividing up the tasks among processors. The benefit of parallel processing, if any, is only evident when you look at the real time via time[real].

time[real](PP({$1..20}));
                             6.113
time[real](PowerSet({$1..20}));
                             4.302

You can also simply replace the seq in PP with Threads:-Seq. It turns out that there is not much benefit to the parallel processing here. But the benefit should increase as computers get more and more processors (I have 8). To make a better comparison, compare procedures where the only change is from seq to Threads:-Seq.

You say "d will be x(t) + a(t)". What is a(t)? Did you mean "d will be x(t) + a[1](t)"?

This brute force technique is far from optimal, especially considering that the sum is converted to a continuous increasing function of N.