Have a look at the EmbeddedComponents help-page in Maple 12.

acer

I had no apparent problems with running the intpakX v1.2 package's compute_all_zeros_with_plot routine, provided that I issued the following call before the module defnition.

with(plots,display,textplot):

After regenerating the module, with the above preceding it, and then loading that package using with, the following example from its user guide worked OK for me in Worksheet mode. Again, you might want to check that you really are recreating the module and that it's not also being picked up from a saved version in libname.

f:=x->sin(exp(sqrt(x-2)));
X:=[8.,10.];
compute_all_zeros_with_plot(f,X,0.001,10,10);

The following also worked for me in Worksheet mode in the Standard GUI (with either Maple Standard or Extended typesetting level as set under Tools->Options->Display),

> A1:=[1,0,1];
> A2:=[-1,1,1];
                             A1 := [1, 0, 1]
                             A2 := [-1, 1, 1]

> A4:=A1 &cmult_opt A2;
               A4 := [-1.390388204, 1.390388204, 2.969562256]

I don't know why it didn't work for you. (I don't know what you C1 is, however. I'm also not totally clear on your Maple version, or interface, or typesetting level.)

While looking for other problematic function names I noticed that the package's init routine also calls with(geometry). That too is a module-based package in Maple 12, and is no longer table-based. Since there are no calls like geometry[somefunction] inside the intpakX sources, it seems "ok" to also issue with(geometry) as another separate command prior to the definition of the intpakX modulein its source. (Again, uses would be a better solution.)

acer

What happens if you remove the space betwene the & and the cmult_opt?

acer

This seems fixable.

If you want to rebuild that package (from its version 1.2 .mw source) then the following command could be inserted right after the restart at its beginning (and before the actual package module code).

with(plots,display):

Alternatively, you could edit the package sources and replace appropriate instances of display with :-plots:-display accordingly. (It could be written better in several repects, but this is probably one way to patch the thing quickly.)

Once the fixed package has been loaded using with the following should work,

X := [0.5,2.];
f3 := x->exp(-x^2)*sin(Pi*x^3);
P1 := compute_range(f3,X,6);
:-plots:-display([P1]);

acer

A solution containing a RootOf may be unfamiliar to the user new to Maple. But it is not meaningless gibberish.

The RootOf acts as a placeholder for the root of an equation which may not be directly expressible. Maple is capable of doing work with such objects, because it some situations they may be usefully manipulated/combined during subsequent computations.

But also, a RootOf can express a exact (non-floating-point) root. That root could be then evaluated to a floating-point approximation at the user's choice of working precision.

For some problems, the work done by `solve` to compute the result can be considerable. If a user wishes to obtain a floating-point approximation, and then to refine that approximation by a repeated floating-point evaluation, it can be much more time  and resource consuming to repeat the entire `solve` call (after replacing some coefficient by its float approximant, say) with a higher setting of Digits. It can be much more efficient to compute the exact RootOf representation once and then to apply evalf[n] as desired.

For example,

> restart:
> e1:=22 - 44*t + 216*t^2 - 66*u - 450*u^2 + 362*u^3:
> e2:=150 - 300*t + 185*t^2 - 450*u + 795*u^2 - 495*u^3:

> _EnvExplicit:=true: sols := solve({e1,e2}):

> evalf(sols);
{t = 0.3553932236, u = 0.2256393210}, {t = -0.392720252, u = 1.261618450},
 
    {t = 1.089017838 + 0.153896733 I, u = 0.7930027610 + 0.4135809565 I},
 
    {t = 0.05432219403 - 0.6134738526 I, u = -0.07035986551 + 0.3340858801 I},
 
    {t = 0.05432219403 + 0.6134738526 I, u = -0.07035986551 - 0.3340858801 I},
 
    {t = 1.089017838 - 0.153896733 I, u = 0.7930027610 - 0.4135809565 I}
 
> evalf[20](sols);
{t = 0.35539322359002767246, u = 0.22563932100319632252},
 
    {t = -0.3927202491803974905, u = 1.2616184500250283042}, {
 
    t = 1.0890178383908523764 + 0.1538967326801938346 I,
 
    u = 0.79300276100467055164 + 0.41358095648073648234 I}, {
 
    t = 0.054322194043184680550 - 0.61347385248733028667 I,
 
    u = -0.070359865507798909630 + 0.33408588008148581458 I}, {
 
    t = 0.054322194043184680550 + 0.61347385248733028667 I,
 
    u = -0.070359865507798909630 - 0.33408588008148581458 I}, {
 
    t = 1.0890178383908523764 - 0.1538967326801938346 I,
 
    u = 0.79300276100467055164 - 0.41358095648073648234 I}

The original posted example does not necessarily raise this performance difference to any great extent. But other problems can. And there are other Maple routines that can compute (approximate) roots of rational polynomial systems (eg. fsolve, etc). My point is purely  about the relative merits of replacing exact equations by floating-point equivalents if the intention is to pass the system to solve.

And RootOf objects should not be avoided for their own sakes (as ostensibly meaningless). There can be benefits to having control over how Maple computes floating-point results. The balance of power and ease-of-use is usually hard to implement best.

acer

These all just showed as blank pages in my firefox browser. Did they work for anyone else?

acer

It's unclear whether you are looking for a floating-point numeric result or not. It may be that you want Int rather than int, but the 2D Math shown here obscures what you're already trying.

Judging by an earlier post of yours, there may also be some misunderstanding about passing functions versus expressions to int (premature evaluation issues, etc).

I suggest posting some 1D (non graphically marked up math) input, with as much of an explicit example as you can.

That error message that you received is likely tied to the particular definition of your integrand. And without more details on f, it's hard to offer concrete advice.

acer

One could create a procedure to do this, perhaps utilizing StringTools:-ParseTime.

The code below could be corrected to adjust more accurately for leap years. (Ie. correct it for years evenly divisible by 100 and by 400, and not simply for years divisible by 4.)

> with(StringTools):
> dt1:=ParseTime("%x","01/01/76"):
> dt2:=ParseTime("%x","01/01/77"):
> dt2:-year*365 + signum(irem(dt2:-year,4))
>   - dt1:-year*365- signum(irem(dt1:-year,4))
>   + dt2:-yearDay - dt1:-yearDay;
                                      366

There is also some accurate data to be had from the Units package. See the ?Units,year help-page, including its Examples section.

acer

You can also solve it using LinearAlgebra commands.

> with(LinearAlgebra):
> A,b := GenerateMatrix([2*x+3*y+z=8,-x+2*y-z=3,3*x-4*y+z=-5],[x,y,z]);
                                [ 2     3     1]  [ 8]
                                [              ]  [  ]
                        A, b := [-1     2    -1], [ 3]
                                [              ]  [  ]
                                [ 3    -4     1]  [-5]
 
> S := Matrix([A,b]); # augmented Matrix, represents system
                               [ 2     3     1     8]
                               [                    ]
                          S := [-1     2    -1     3]
                               [                    ]
                               [ 3    -4     1    -5]
 
> RowOperation(S,[2,1]); # exchange 1st and 2nd rows
                            [-1     2    -1     3]
                            [                    ]
                            [ 2     3     1     8]
                            [                    ]
                            [ 3    -4     1    -5]
 
> RowOperation(%,1,-1); # scale 1st row by -1
                             [1    -2    1    -3]
                             [                  ]
                             [2     3    1     8]
                             [                  ]
                             [3    -4    1    -5]
 
> RowOperation(%,[2,1],-2); # add -2 times 1st row to 2nd row
                             [1    -2     1    -3]
                             [                   ]
                             [0     7    -1    14]
                             [                   ]
                             [3    -4     1    -5]

You should be able to do the rest, if you know how Gaussian elimination works.

You mentioned `solve`.

> solve([2*x+3*y+z=8,-x+2*y-z=3,3*x-4*y+z=-5],[x,y,z]);
                            [[x = 1, y = 2, z = 0]]

> LinearSolve(A,b);
                                      [1]
                                      [ ]
                                      [2]
                                      [ ]
                                      [0]

acer

How you go about it depends on the actual data structures that contain your data. (In Maple lists are not arrays, and are not Vectors, etc.) Your post seems to indicate that you want the data put in the form of a list of lists.

Also, there are often a few ways to do such things.

> X,Y:=<1,2,3>,<7,8,9>: # two Vectors
> <X|Y>;
                                   [1    7]
                                   [      ]
                                   [2    8]
                                   [      ]
                                   [3    9]
 
> convert(<X|Y>,listlist);
                           [[1, 7], [2, 8], [3, 9]]
 
> [seq([X[i],Y[i]],i=1..min(op(1,X),op(1,Y)))];
                           [[1, 7], [2, 8], [3, 9]]
 
> X,Y:=[1,2,3],[7,8,9]: # two lists
> zip((a,b)->[a,b],X,Y);
                           [[1, 7], [2, 8], [3, 9]]
 
> [seq([X[i],Y[i]],i=1..min(nops(X),nops(Y)))];
                           [[1, 7], [2, 8], [3, 9]]
 
> kernelopts(version);
            Maple 9.03, IBM INTEL LINUX, Oct 1 2003 Build ID 141050

acer

I have this problem with using my own ISP's own (yahoo-based) webmail service from home, or when accessing my workplace's (Outlook) webmail. The only solution of which I'm aware it to ask people to resend their attachments, compress/zipped/gzip'd.

Doug mentioned a severe case of this here.

This could be fixed by Maplesoft, by implementing automatic compression/decompression in the Maple product (Standard GUI) itself. It's not clear how that would affect functionality which depended on worksheets' being in plaintext. Perhaps the GUI could be changed to handle both compressed and uncompressed instances of worksheets.

acer

If one uses plaintext files to store the Maple source code then it is possible to set this up using the $include, $define, and related directives. The basic idea is this:

• set up code in separate text files
• have master text code file $include them
• use $define to set values (like your fix_A) in source files
• have master file `savelib` procs to .mla, using libname
• access .mla in other (eg.GUI) sessions using libname

The benefits of this are several. For one thing, the source code is very safe, as plaintext. (Have you ever had a corrupt worksheet, from which you could not extract your code?) Also, a revision control system such as RCS works much better with code as plaintext. And also it gives the main benefit that you've described -- the source can be well-organized.

The trick is that those directives only work in the commandline interface of Maple. In MS-Windows this is called cmaple.exe, and normally runs in what looks like an old DOS window. The commandline interface of Maple is a joy on Linux, but less pleasant on Windows. It can be made easier by using cygwin on Windows to get a nice shell.

I have been wanting to write a tutorial on this, for the mapleprimes book section, for a while now. But it's hard to find the time.

acer

That quoted sentence does seem to be offering to compute and return the L. I agree that the pair of nouns "factor" and "Matrix" are a little grammatically dubious there, side by side. I see where this comes from now -- it's the tooltip on a context-sensitive submenu item that shows when one right-clicks on a Matrix as output.

You may already know the following, and since I'd already typed it out...

PLU is Gaussian elimination in mild disguise. Normally, when one does GE one does not keep track of the row swaps or the pivoting  divisions/addtions. One usually just keeps the  Matrix on which those actions take place. That Matrix  ends up being the U of PLU.

But the other information can be stored too (but isn't usually, in the GE that one learns in a first course). The row swaps (when there is a choice of pivot, when working on given leading column) can be stored in the P. The pivoting actions can be stored in the L.

What makes PLU extra attractive is that, having expended the O(N^3) cost of factorizing A=PLU once, one can then apply that to solving multiple RHSs which is only a further O(N^2) cost of forward- and back- substituting. One can backwards substitute by using the U, and then forwards substitute using the L.

In Maple, the ConditionNumber, MatrixInverse, and LinearSolve routines accept the P and LU in lieu of Matix A. They allow one to capitalize on doing the factorization  (just) once.

ps. I believe that, if one looks at it the right way, Cholesky can be seen as a form of LU as well.

acer

Here's another way,

> with(Units:-Standard,sin,cos):

> sin(30*Unit(degrees));
                                      1/2
 
> cos(30*Unit(degrees));
                                      1/2
                                     3
                                     ----
                                      2

Note that this approach doesn't make inverse trig operations return results in terms of degrees.

> Units:-Standard:-arcsin(1/2);
                                      Pi
                                     ----
                                      6

acer

This can be done is several ways. Here is one way, which allows one to use the name sin while retaining the original as :-sin.

> T := module() option package;
> export sin, cos;
>   sin := proc(x) :-sin(x*Pi/180); end proc:
>   cos := proc(x) :-cos(x*Pi/180); end proc:
> end module:

> with(T);
                                  [cos, sin]
 
> sin(30);
                                      1/2
 
> :-sin(Pi/6);
                                      1/2

acer