The fascinating manner in which ArrayTools:-SearchArray varies the number of items in its returned expression sequence relies on _nresults

Now, _nresults is part of parameter-processing. and has been present since Maple 10. It's not very "Maple-like" behaviour, though, which might be why it's not usually seen even in new system commands.

The  ArrayTools:-SearchArray command seems intended to mimic that Matlab `find` command (excluding the underdocumented acceptance by the Matlab command of a qualifier in the argument, eg. X<3) and so may reasonably appear un-Maple-like.

ps. The Mapleprimes functionality to automatically recognize help-page references doesn't work for ?_nresults at the time I write this.

As a general rule, a module has to be savelib'd to a .mla Library archive (repository) and not to a .m file, if it is to be saved fully intact.

If there is no writable .mla archive in the savelibname (or libname) path then Maple will write out to a .m ("dotm") format file instead.

And, in general, a module is not fully encapsulated when saved to a .m file. That should be better documented. But there it is.

Workarounds are to either assign savelibname to a particular .mla filename, or to a directory which contains a writable .mla archive. That's good practice in general, or else lots of savelib() calls will litter some directory instead of nicely saving any individual .m's to a .mla container.

FWIW, that is related to why customized context-menu actions do not work properly on modules as the display output. The GUI-kernel interaction for it is somehow dotm based, and only a shell of the module object gets received by the context-menu package's code. This is a shame, given how long modules have been in Maple.

The Example in ?LibraryTools,Create should use the currently supported .mla and not the old deprecated .lib/.ind filename extensions.

It might be better if the tools were more user-friendly. The `savelib` command could issue an error if no writable archive were present, and suggest using `save` instead. The `save` command could issue an error if told to save a module whichit could not fully handle. And so on. I bet something better is workable, while only losing "misfunctionality".

acer

After reading through all the followups in this thread, I would suspect that the problem is that the mount of a network filesystem is sporadically failing, and then the execution is aborted.

If that guess is the case, and if you are lucky then it could be due to Maple trying to write to a file in a directory whose NFS mount has suddenly disappeared. You might be able to work around that, for your very long maple sessions, by appending/writing/reading only to/from files on local disk, such as in the /tmp directory.

If it guess is the case, and if you are less lucky, then the networked mount point on which Maple resides may itself be failing now and then. To work around that, you could try installing Maple on local disk (eg. /usr/local for Linux/Unix).

Basically, if the appearance of .nfsXXXXXX files during each crash is a true indication that the problem is due to a sporadically failing network file system (NFS) then you may be able to work around it by having both Maple and all personal i/o data files be on local disk.

ps. anames(user) and any other variable values will not collide amongst different/distinct Maple kernels or running sessions of the commandline interface.

acer

@mehrdadparsapour 

If you look carefully enough at the results resturned by `solve` in both my and John's earlier answers you should be able to see that they do in fact contain such formulae. That is, they contain answers of the form a=..., b=... in terms of X.

But the right-hand-sides of those answers like {a=..,b=...} in terms of X are implicit RootOfs, and not explicit arithmetic formulae in terms of radicals.

You may not like that implicit RootOf form. But as I showed it is useful. Using evalf or fsolve following substitution of X by a float value (as I showed using evalf), all the roots for any given numeric X can be obtained. Hence, you can much more easily and reliably obtain all the roots of those RootOfs involving simple polynomials in X (for any given numeric X) than you can obtain roots of the system of equations using fsolve (for any given numeric X).

The extra RootFinding:-Parametric bit I added in my worksheet, before the `solve` stuff, was to show how many roots (ie. distinct sets of values for a,b,c,d) there are for separate ranges of real-valued parameter  X.

acer

A:=[($1..6)];

Matrix(3,2,[ListTools:-LengthSplit(A,3)],scan=columns,order=C_order);

acer

Try setting,

interface(prettyprint=1);

beforehand. That has the advantage that the result might be expressed tersely enough for you to gain whatever insight you'd expected to get by looking at it.

Or you could suppress the output using a full colon instead of a semicolon at the end of the line (and then figure out how to pick apart and make sense of the unviewable answer).

acer

You can use a mix of the RootFinding:-Parametric package and the `solve` command here.

Perhaps someone could check this over and explain how to reliably obtain the cell boundaries from RootFinding:-Parametric's results, in the single-parameter case. I find the output from CellDescription to be opaque.

param.mw

I was unable to insert the above worksheet's contents directly into this post, getting error messages from Mapleprimes about maplenet.

acer

The first version of Maple supported for Vista by Maplesoft was 11.01.

See here.

acer

If you use the Sockets package, then yes it should be possible for maple to negotiate the SMTP port connection and actually send the email (without `system` calls).

Look here, and perhaps in particular at the example.

I know at least one person who has claimed in conversation to have successfully written such an animal.

acer

Please stop posting duplicates of this earlier post of yours. Just correct the original, if you made mistakes in it, or in its uploaded worksheet.

What makes you think that the exact symbolic inverse of a (pretty general, even if triangular)  6x6 Matrix is going to be anything useful?

Is the non-blocked version of your C.C^%T singular? Did you really intend on having non-invertible blocks, or did you make a mistake in the code that creates each of them? Did you instead want all those entries to be distinct symbols, rather than identical-per-subblock?

What do you intend on doing with any solution, anyway? Are you planning on pumping in values for the x's, at some later time? Because if that is so then why not consider purely numerical solving? (You never responded to an earlier suggestion to a similar question, BTW.)

acer

C:=LinearAlgebra:-LUDecomposition(A,'method'='Cholesky','output'='L');

C.C^%T;

The option output=L is not necessary, as it is the default form returned for method=Cholesky. See here for lots more detail.

acer

> L:=[[name,4,3,6,5],[3,5,name],[3,6,1,2,9,8]];
     [[name, 4, 3, 6, 5], [3, 5, name], [3, 6, 1, 2, 9, 8]]

> map2(remove,`=`,L,name);
           [[4, 3, 6, 5], [3, 5], [3, 6, 1, 2, 9, 8]]

> map2(remove,`=`,L,3);
         [[name, 4, 6, 5], [5, name], [6, 1, 2, 9, 8]]

> map2(member,name,L);
                      [true, true, false]

acer

You can use the Matrix constructor for this, since it provides for an operator initializer of the entries.

c:=Matrix(2,2,(i,k)->i+k):
b:=Vector(2,(i)->i+1):

M:=Matrix(2,2,(i,k)->`if`(i=k,b[i],c[i,k]));

You can replace the 2,2 above with something that returns the dimensions directly. For example, since c above is a Matrix,

> op(1,c);
                              2, 2

So in this case you could also do,

M:=Matrix(op(1,c),(i,k)->`if`(i=k,b[i],c[i,k]));

And of course you could also use your formulae directly,

M:=Matrix(2,2,(i,k)->`if`(i=k,i+1,i+k));

acer

Yes, it should be possible to call such an engine from Maple. But it's likely that it would only be done indirectly, via an intermediary layer written in C, say, to translate between Maple and Mosek data structures and do Mosek initialization.

acer

You can try things like this,

> discont(diff(tan(x),x),x);
                                {Pi*_Z1+(1/2)*Pi}

> discont(diff(abs(x),x),x);
                                       {0}

There is also fdiscont, which uses floating-point approximations.

You might also try your luck a bit with `is` and `coulditbe`, although those wouldn't tell you where (they're for functionals, in this context?).

You can pick apart a piecewise with `op`.

acer