I suspect that what was mostly needed, for the usenet poster's request, was to overload (and possibly redefine) mvMultiply.

The bit about redefining :-`*` was perhaps not necessary at all. I thought that I had not been able to get it all to work satisfactorily without the :-`*` redefinition. But I could well have made a mistake.

But now I reread the bit about how overloaded operators may not get used in routines saved to (and read in from) a Library archive. So perhaps it was necessary, in order to get that part of it to work. Maybe someone else can try, with a simple example using a saved, non-builtin Library routine.

The 4th bullet point on the ?overload help-page indicates that the previous binding will be used as a fall-through. The ?use help-page also lists operators that can be rebound, with some extra discussion.

The introduction of type `*` was likely only necessary on account redefining :-`*`.

acer

On the help-page ?evalf,Int you can see that the tolerance can be set independently from the working precision.

evalf(Int(...)) takes an optional argument of the form 'epsilon'=value to specify the requested tolerance. I believe that it is relative tolerance, for most of its methods. And it takes an optional argument of the (lowercase) form 'digits'=value to specify the working precision.

Now, normally evalf/Int will set epsilon as something like one half ulp, according to Digits (or the digits argument). That can sometimes present numerical difficulties. But you can keep the epsilon fixed (using the optional argument) to as low as is acceptable, and then crank up the working precision (using the optional argument) as high as you wish. In this way you might gain some assurance that, say, any bad numerical conditioning of the problem has been overcome and that the estimated error estimates are actually valid (while being below the requested error tolerance).

Setting infolevel[`evalf/int`]:=1 should provide some additonal printed outout about, say, the estimated error levels.

acer

On the help-page ?evalf,Int you can see that the tolerance can be set independently from the working precision.

evalf(Int(...)) takes an optional argument of the form 'epsilon'=value to specify the requested tolerance. I believe that it is relative tolerance, for most of its methods. And it takes an optional argument of the (lowercase) form 'digits'=value to specify the working precision.

Now, normally evalf/Int will set epsilon as something like one half ulp, according to Digits (or the digits argument). That can sometimes present numerical difficulties. But you can keep the epsilon fixed (using the optional argument) to as low as is acceptable, and then crank up the working precision (using the optional argument) as high as you wish. In this way you might gain some assurance that, say, any bad numerical conditioning of the problem has been overcome and that the estimated error estimates are actually valid (while being below the requested error tolerance).

Setting infolevel[`evalf/int`]:=1 should provide some additonal printed outout about, say, the estimated error levels.

acer

I mentioned that T should be a list, not a set, for that particular `sort` idea.

Note the use of [ ] brackets, rather than { } brackets,

> T:= [op(map(x->[x,Occurrences('x',rolls)],rolls))];

                  T:= [[1, 1], [4, 2], [5, 2]]

acer

I mentioned that T should be a list, not a set, for that particular `sort` idea.

Note the use of [ ] brackets, rather than { } brackets,

> T:= [op(map(x->[x,Occurrences('x',rolls)],rolls))];

                  T:= [[1, 1], [4, 2], [5, 2]]

acer

Good job so far. Now you can use the `sort` routine (on T as a list rather than a set).

It works by sorting according to size of the second element

>  T:=[[1, 1], [4, 1], [5, 1], [6, 2]];
                     T := [[1, 1], [4, 1], [5, 1], [6, 2]]
 
> sort(T,(a,b)->a[2]>b[2]);
                       [[6, 2], [5, 1], [4, 1], [1, 1]]

There are more efficient and involved ways. But this should work for your task, and is simple.

acer

Good job so far. Now you can use the `sort` routine (on T as a list rather than a set).

It works by sorting according to size of the second element

>  T:=[[1, 1], [4, 1], [5, 1], [6, 2]];
                     T := [[1, 1], [4, 1], [5, 1], [6, 2]]
 
> sort(T,(a,b)->a[2]>b[2]);
                       [[6, 2], [5, 1], [4, 1], [1, 1]]

There are more efficient and involved ways. But this should work for your task, and is simple.

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

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