So perhaps there is no need to expand the terms. In Maple, evalf(Int(...)) does numerical quadrature.

Of course, there is still the working precision, and some requested error tolerance, to be considered. With such large exponents and small constants, I wouldn't be surprised if the working precision had to be high (and so higher than fast double precision). And sometimes things like this can matter.

How much accuracy do you need?

acer

So perhaps there is no need to expand the terms. In Maple, evalf(Int(...)) does numerical quadrature.

Of course, there is still the working precision, and some requested error tolerance, to be considered. With such large exponents and small constants, I wouldn't be surprised if the working precision had to be high (and so higher than fast double precision). And sometimes things like this can matter.

How much accuracy do you need?

acer

I was thinking about this a while back...

I first got curious after looking at Maple 12's Explore:-explore routine, which gets used by the new "Explore" context-sensitive menu entry. Basically, this routine works by reading in a template .mw using XMLTools:-ReadFile, manipulating the template a bit with subs, then calling INTERFACE_WORKSHEET on the result. It reads in a template, fills in with a number of sliders (to correspond to free variables), and opens the result in new tab in the Standard GUI. The template already has some GUI components inside it.

I see the template files under here, in my Maple 12 Linux installation,

<maple12>/data/assistants/

So far, so fun. I made a few different template .mw files of my own, to try things like building a non-Maplet Matrix browser. I set some appropriate parts as auto-execute. And in some circumstances INTERFACE_HELP might be used to generate the display.

Then I just started editing .mw files in vi. And then I started looking at what XMLTools does. This is where it gets tricky.

In theory, we should be able to create a suite of Maple procedures which can emit the appropriate (nested calling) tree data structure that XMLTools can then convert into .mw form. It should be possible to create such procedures so that they allow one to read, edit, and write out the XML source with the Maple GUI's embedded components in it. But it's not completely easy, even with the schema stuff under,

<maple12>/data/xml/schema/worksheet/

It might be nicer with a DOM set up for worksheets. Part of the trouble (or so it seemed to me) was the lack of names for the nodes. Perhaps one could walk the Maple structure given by XMLTools and put an attribute on each node to specify both a name and the name of the parent. Perhaps something like SPATH might help.

The basic idea is that, even if one cannot edit the GUI components inside the current worksheet, it might be possible to programatically read in, edit and augment, and write-out or display in a new tab a worksheet with embedded components.

I believe that this mapleprimes community has enough talent to design such procedures, if it so wished.

ps. This is why I was asking about the format of images embedded in .mw files.

acer

What exactly you are trying to do is still unclear to me.

It shouldn't make a difference whether the Matrix is a global of the procedure or is returned by that procedure, as far as subsequently exporting to Matlab formats goes.

If you do,

M := get_quantities(..blah..);

then M gets assigned the Matrix returned by get_quantities. You can deal with that as easily as with something declared as global inside the procedure.

You didn't describe cutting and pasting in the original post. You shouldn't have to resort to that, to get data from Maple into Matlab. See the ?ExportMatrix help-page, which describes how to write a Maple Matrix out to a file in Matlab format.

acer

What exactly you are trying to do is still unclear to me.

It shouldn't make a difference whether the Matrix is a global of the procedure or is returned by that procedure, as far as subsequently exporting to Matlab formats goes.

If you do,

M := get_quantities(..blah..);

then M gets assigned the Matrix returned by get_quantities. You can deal with that as easily as with something declared as global inside the procedure.

You didn't describe cutting and pasting in the original post. You shouldn't have to resort to that, to get data from Maple into Matlab. See the ?ExportMatrix help-page, which describes how to write a Maple Matrix out to a file in Matlab format.

acer

Consider the first set of manipulations that you did: All done at Digits=14, and convert(expr,rational) versus convert(expr,rational,exact), and so on.

I suspect that you have, in those steps, set up a problem which is quite different. It's not the same as the OP's problem. So perhaps it's no wonder that the result is different from what I obtained.

Once the new problem might get cast, it probably doesn't matter at what value of Digits its evalf/Int is computed. You might just be computing the different answer of a slightly different problem (but computed at higher and higher accuracy, yet still for the different problem).

I could be wrong, but that's how it seems to me.

acer

Consider the first set of manipulations that you did: All done at Digits=14, and convert(expr,rational) versus convert(expr,rational,exact), and so on.

I suspect that you have, in those steps, set up a problem which is quite different. It's not the same as the OP's problem. So perhaps it's no wonder that the result is different from what I obtained.

Once the new problem might get cast, it probably doesn't matter at what value of Digits its evalf/Int is computed. You might just be computing the different answer of a slightly different problem (but computed at higher and higher accuracy, yet still for the different problem).

I could be wrong, but that's how it seems to me.

acer

> 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

> 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