> expr := (sin(ko*W/2*cos(theta))
> /cos(theta))^2*sin(theta)^3*BesselJ(0,ko*L*sin(theta)):

> limit(expr,theta=Pi/2);
                                2  2
                          1/4 ko  W  BesselJ(0, ko L)

acer

Hi Axel,

Could you please explain exactly why you think that the integration result may not be obtainable?

acer

Hi Axel,

Could you please explain exactly why you think that the integration result may not be obtainable?

acer

For very large symbolic computations, memory (RAM) can really matter. Consider a 64bit platform if you need to install and use a huge amount of memory (eg. more than 2GB).

For large scale hardware modular integer or double-precision floating-point linear algebra Maple can take advantage of multiple core CPUs (not hyperthreaded, but true SMP or multi-core). See here.

For computation with very large integers (or at very high floating-point precision) Maple's use of GMP matters. See some comments here.

For some very general comments on relative performance differences between 32bit and 64bit Maple implementations, see here.

On Linux (and OSX?) some use of fast compiled double-precison special functions (J0, J1, etc) is easy. See here. GSL may be a viable alternative across platforms.

Multi-core doesn't (yet) make much difference in general symbolic computations, as Maple's Threads package is still young.

If memory use is critical, consider Linux as a platform, on which using Maple's lightweight commandline interface is very easy. Note that, on OSX, there is no Classic Maple graphical interface (which is much lighter in memory use than the Java-based Standard graphical interface).

There used to be a difference in relative performance difference between AMD and Intel CPUs for both hardware integer and hardware floating-point operations. I do not know whether this is true of the latest CPUs.

acer

The enterprising student might also write a variant on this procedure, using methodology from Joe's first post above.

Instead of taking in the a,b pair for the modular affine map as parameters, the procedure might accept a list of transformation guesses, eg. ["a"="  ","e=" e"]. It could then find the numeric places of those letters, solve for a and b within the procedure, and output the result of using that en/decryption.

acer

The enterprising student might also write a variant on this procedure, using methodology from Joe's first post above.

Instead of taking in the a,b pair for the modular affine map as parameters, the procedure might accept a list of transformation guesses, eg. ["a"="  ","e=" e"]. It could then find the numeric places of those letters, solve for a and b within the procedure, and output the result of using that en/decryption.

acer

Usually, if it can be plotted numerically then it can also be maximized numerically as well, to get better accuracy. If the plot is successful, then it's quite likely that some form can be optimized as well.

As pointed out, there is some problem with unevaluated summations inside the objective expression, due to innappropriate recognition of the dummy index as if it were an independent variable. That bug may well affect products and limits as well.

If one knows that the general summation call will result in an unevaluated summation expression, then one may instead supply the objective to Maximize in operator form (so as to allow it to be computed using evalf@Sum).

> g:= x -> x*Sum(i^(-5/2)*exp(-i*x),i=1..infinity):

> Optimization:-Maximize(g,0..2);
                [0.397154744381517988, [0.915476581931277900]]

In any event, the OP asked for a solution using the plot, and that is what Robert replied with. Seems perfectly sensible to me.

acer

Usually, if it can be plotted numerically then it can also be maximized numerically as well, to get better accuracy. If the plot is successful, then it's quite likely that some form can be optimized as well.

As pointed out, there is some problem with unevaluated summations inside the objective expression, due to innappropriate recognition of the dummy index as if it were an independent variable. That bug may well affect products and limits as well.

If one knows that the general summation call will result in an unevaluated summation expression, then one may instead supply the objective to Maximize in operator form (so as to allow it to be computed using evalf@Sum).

> g:= x -> x*Sum(i^(-5/2)*exp(-i*x),i=1..infinity):

> Optimization:-Maximize(g,0..2);
                [0.397154744381517988, [0.915476581931277900]]

In any event, the OP asked for a solution using the plot, and that is what Robert replied with. Seems perfectly sensible to me.

acer

No, that's not true.

The OP did not specify whether the sequence should be split starting from the left or the right. It may have been what he meant (left to right, starting with most significant digits) or it may not. He really didn't say. His example was a multiple of 3 in length, so splitting by groups of 3 digits looks the same starting from either direction.

Even if the OP further clarifies, the original post still lacks the information about direction. In that absence, it's not true to say that either direction is incorrect.

I gave two methods. One works from left to right, and the other from right to left. (They also reverse the order of the results, but that's irrelevant since ListTools:-Reverse is easy to do.)

> f(1234567890);
                              [123, 456, 789, 0]

ListTools:-Reverse(g(1234567890));
                              [1, 234, 567, 890]

acer

No, that's not true.

The OP did not specify whether the sequence should be split starting from the left or the right. It may have been what he meant (left to right, starting with most significant digits) or it may not. He really didn't say. His example was a multiple of 3 in length, so splitting by groups of 3 digits looks the same starting from either direction.

Even if the OP further clarifies, the original post still lacks the information about direction. In that absence, it's not true to say that either direction is incorrect.

I gave two methods. One works from left to right, and the other from right to left. (They also reverse the order of the results, but that's irrelevant since ListTools:-Reverse is easy to do.)

> f(1234567890);
                              [123, 456, 789, 0]

ListTools:-Reverse(g(1234567890));
                              [1, 234, 567, 890]

acer

I can never tell whether members who post questions in the Student forums are trying to learn some quick way (single routine call, say) or are hoping to figure out "how it works". Hopefully they get good coverage of both here, in general.

acer

I can never tell whether members who post questions in the Student forums are trying to learn some quick way (single routine call, say) or are hoping to figure out "how it works". Hopefully they get good coverage of both here, in general.

acer

It really should be possible to change Maple's Standard GUI so that it will compress/decompress worksheets on the fly.

If this is already being done for ebooks then that serves as proof of concept. But even if on-the-fly compression/decompressiom has to be implemented technically differently for regular worksheets than for ebooks, it should still be possible.

acer

It really should be possible to change Maple's Standard GUI so that it will compress/decompress worksheets on the fly.

If this is already being done for ebooks then that serves as proof of concept. But even if on-the-fly compression/decompressiom has to be implemented technically differently for regular worksheets than for ebooks, it should still be possible.

acer

Is the problem that the contents of the Array are not right, or that it gives a Warning, or that you cannot see the contents?

Ie, did you try it after,

interface(rtablesize=100):

The numeric output seems fine for me in both 32bit and 64bit Linux, with no Warning, with 12.01.

acer