The multiplicands in the product returned by ifactor have to be prevented from automagically multiplying together, otherwise one would never get a chance to actually see the factored result. This is done by returning the factors as function calls to ``(). Besides preventing the re-multiplication, the ``() function calls have the useful property of being nicely (invisibly) typeset.

You can also get the contents using op() once more.

> sol := ifactor(3^43+1);
                                2
                     sol :=  (2)   (82064241848634269407)
 
> lprint(sol);
``(2)^2*``(82064241848634269407)

> lprint(op(2,sol));
``(82064241848634269407)

> op(op(2,sol));
                             82064241848634269407
 
> expand(op(2,sol));
                             82064241848634269407

> dismantle(%);
INTPOS(6): 82064241848634269407

acer

When I get a few moments I ought to be able to come up some calls to dstebz and dstein (or nonsymmetric equivalents) from clapack, to compute eigenvectors of only selected eigenvalues. Since double-precision clapack 3.0 is bundled with Maple, that sort of thing is often not hard to set up. (One could also use a wholly separate clapack 3.2.x, or arpack, but that requires building it with everything exported and with the right conventions).

The is nothing in Maple for sparse eigensolving, and the conversion ("exploding")  operation from sparse to dense is sometimes unfortunately slow. So you might be better off getting rid of the storage=sparse and stick with the dense 'rectangular' storage. Also, I notice that you have datatype=float so you may wish to ensure that Digits<=trunc(evalhf(Digits)) when those Matrices are created (so that it resolves float->float[8]).

acer

If I might try to clarify just one or two minor aspects of Robert and Alec's good responses:

It is not neceesary to "load" the entire package by issuing the with(LinearAlgebra) command. Even without having issued that command, the individual routines in the package are available using their long form. Eg,

LinearAlgebra:-SingularValues(M);

Given a Matrix, one can right-click on its output and get access to quite a few linear algebra operations using the so-called context-sensitive menus. This is the case even without "loading" the package using with(...).

The call to with(...) merely rebinds the package's exported routines' names, so that they can be called conveniently in their short form.

In 2D Math entry mode (the default for new users) LinearAlgebra:-Determinant may be invoked by placing single | bars around a Matrix, eg. |M| where M is assigned to be a Matrix.

acer

The length of Z and Ay must match. You have them with 18 and 19 elements respectively.

It's CurveFitting, not CureFitting.

acer

G := `#mi("\`The calculation was interrupted.\`",mathcolor = "red")`;

print(G);

acer

What do you want a 3D hypermatrix to be? Do you want an m by n by k Array, or a k-Array or m by n Matrices, or...? How do you want to be able to reference its entries or slices? Are you after something other than a tensor?

acer

Since you asked about how to do this here, you are presumably doing this for sin as an export of a module. And that is OK (others who replied here likely did not realize that you'd been shown how to do it in a module).

In Maple 13.02, in the commandline interface I get output that looks like this,

> m := module() option package; export sin;
> sin := proc(x):-sin(x*Pi/180);end proc:
> end module:
> with(m):
> sin(x);
                                       x Pi
                                   sin(----)
                                       180
 
> Eval(y=sin(x),x=30);
                            /        x Pi \|
                            |y = sin(----)||
                            \        180  /|x = 30

In the Standard GUI I also see similar 2D Math output. In particular, unlike in your post, the x*Pi/180 gets formatted as a visual 2D fraction. Was that what you objected to? (You used Eval rather than eval, so presumably your objection is not that it did not evaluate.)

acer

The first error message is indicating that it failed to write into any of the Library archives in Maple's own installed location. That's safe behaviour, preventing inadvertant permanent clobbering of anything in Maple itself. The second error message is due to the prior failure to save the module.

Try creating a Library archive (.mla file) that is owned and writable by yourself, in a personal folder of your own. See the help for LibraryTools,Create. Then adjust libname in subsequent (or restarted) sessions, so that it can be found.

acer

Try using the fflush command.

acer

> a1_Func := (t)-> t^2 + t + 1;
                                           2
                          a1_Func := t -> t  + t + 1
 
> a2_Func := D(a1_Func);
                            a2_Func := t -> 2 t + 1
 
> a1_Func(4);
                                      21
 
> a2_Func(4);
                                       9

acer

The Units Calculator (Assistant) is (in Maple 12 and 13) just a worksheet with some embedded components and some hidden code (collapsed/hidden document blocks, and bits of various component-property code). You can edit that code, and it shouldn't be very hard to add more conversions to it.

You could actually save the worksheet that shows the Calculator, when finished. Then you could launch it when you wanted (either using File->Open, or using an `INTERFACE_WORKSHEET` call, or replacing the renamed installed original if you felt brave).

But is that what would really help you? The results of that Assistant cannot be returned directly to your original worksheet, can they? So you'd have to cut and paste them, in order to make further use of the results.

Perhaps you'd find it just as useful to call convert/units?

> 1 / convert(17., 'units', miles/gal, 100*km/L );
                                  13.83615196

> 1 / convert(35., 'units', miles/gal, 100*km/L );
                                  6.720416667

You could write short procedures to convert, say, back and forth between miles/gallon and litres/100km. You could save those procedures in a .mla Library archive, for quick re-use in any worksheet. You could then call them straight, or you could insert a pair of input/output components in any new worksheet that needed them dynamically. Then the values could be assigned (to globals in the component property code, say) and programmatically re-used outside of the components. Or you could write (and save-to-archive) a re-usable Maplet that could also return the results directly.

acer

This is just string manipulation. If it doesn't quite do what you're after then it should be easy to adjust. I wasn't sure to which length you wanted to pad with zeros in the hex representation. (I chose 4, but changing that is simple.)

> p := proc(x::string)
> local xlength, n, paddedx, i, r;
> n:=iquo(length(x),4,'r');
> if r<>0 then n:=n+1; paddedx:=cat(seq("0",i=1..(4-r)),x);
> else paddedx:=x; end if;
> cat(seq([StringTools:-LengthSplit(paddedx,2)][n*2-i+1],
>         i=1..n*2));
> end proc:

> X:="18DBD3547552C73BE4DE87731C500":
> p(X);
                      "00C53177E84DBE732C554735BD8D0100"

> p("DCBA9876");
                                  "7698BADC"
 
> p("DCBA987654");
                                "547698BADC00"

If you wanted to take your original base-10 number X (as a numeric rather than as a string) and convert to hexadecimal using Maple's convert(X,base,16), then the procedure could act similarly but do equivalent list manipulation instead.

acer

See here.

acer

I suspect that the problem relates to lack of special evaluation rules some place under Units:-Standard:-add, so that it tries to evaluate x[k] an rtable reference for unspecified k. Maybe that gets caught, and a bad arguments error re-thrown. Just a guess.

The quantities being added have just simple units attached to them all (meters). So It's not necessary to get the smarts of Units:-Standard:-add in order to add them up while resolving different mixed units. So :-add should suffice.

In short, it may be that replace those sum calls with :-add calls could work, while keeping the subpackage loading by with(Units:-Standard).

There's a later error for assign(%), but perhaps that is an oversight by the author.

BTW, the line with Units[UseSystem](SI) appears to be plain text and not a command. But that's the default anyway, so it'd make no difference.

Oops I submitted this as reply to the main thread, while it relates to Doug's subthread. Sorry.

acer

I don't think that the mistake was entirely of your doing. It's understandable.

Suppose it were the case that, for actual Matrices, the implicit multiplication (using space) were to return an error message such as "implicit multiplication not allowed for Matrices and Vectors, use . (dot) instead". People would quickly learn to use `.` instead of trying to use space, for Matrix/Vector multiplication.

Now consider what would happen if the implicit multiplication were to get some delay, so that dispatch to `.` vs `*` is done at run time instead of code for either call being inserted by the 2D Math parser. That scheme might work. But it might lead to some new bugs, as is the way of things. And it would involve another function call, which would make running such 2D code slower than running the 1D equivalent. Sure, it's just one function call, but inside nested loops....  Overhead creeps up.

By the way, if I recall your worksheet does something like this,

N . MatrixInverse(M);

For floating-point data that is not always numerically best. You can also use LinearSolve, which may have some more robust numeric behaviour (in problematic cases).

Transpose(LinearSolve(Transpose(M),Transpose(N)));

In order to keep it efficient, either all those transpositions can be done in-place, or the code might be reworked so that the transposed data is both generated and subsequently expected (thus removing the need for Transpose calls).

acer