MuPAD comes with a very full-featured programming language. So much so, that I would say that this is one of MuPAD's greatest strengths. In contradistinction to other CASs, MuPAD allows:
object oriented programming
It would take far more than an introductory exposition such as this to even scratch the surface of MuPAD's programming power, so we shall just look at a few simple examples. For more involved examples, try the expose command, or look at some of the files in your $MuPAD/share/examples directory.
For procedural programming, MuPAD offers all the standard programming requirements: loops of various sorts, branching, and recursion. Here, for example, is a simple procedure designed to implement Hofstadter's chaotic function, with line numbers as shown:
1 q:=proc(n) option remember; 2 begin 3 if n<=2 then 4 1 5 else 6 q(n-q(n-1))+q(n-q(n-2)) 7 end_if; 8 end_proc;
Suppose we create a small file called Hofstadter.mu containing these lines, and we read it into MuPAD with
>> read("Hofstadter.mu");This will make the function q(n) available to us. We can then list the first 20 values:
>> q(i)$i=1..20; 1, 1, 2, 3, 3, 4, 5, 5, 6, 6, 6, 8, 8, 8, 10, 9, 10, 11, 11, 12Or we can graph the first ten thousand values:
>> plot2d([Mode = List,[point(u,q(u)) $ u=1..10000]]);A few points about this simple procedure: the option remember in line 1 means that values generated by the function are automatically stored where they can be retrieved if needed. With all the nested recursion, evaluating function values without using previous values would be hideously slow. The syntax is pretty standard, and is very similar to that of Maple.
We can define simple functions very readily by using an “arrow” definition:
Curiously, I can't find any reference to this in the manual.
For a slightly more involved example, suppose we try to write a program to generate truth tables. That is, so that something like
>> tt(p and q);
p, q, p and q T, T, T T, F, F F, T, F F, F, FTo make things easy for ourselves, we shall include the variables of the boolean expression in the function call, so as to save the bother of parsing the expression to obtain its variables. And here is such a program:
1 tt:=proc() 2 local i,j,n,l,ft,f,r,rf; 3 begin 4 if args(0) <= 1 then error("Must include all variables"); 5 end_if; 6 7 ft:=[FALSE,TRUE]; 8 n:=args(0)-1; 9 print(Unquoted,args(j)$j=2..args(0),expr2text(args(1))); 10 11 for j from 2^n-1 downto 0 do 12 f:=args(1); 13 14 for i from 1 to n do 15 l[i]:=floor(j/(2^(n-i))) mod 2; 16 end_for; 17 18 for i from 1 to n do 19 f:=subs(f,args(i+1)=ft[l[i]+1]); 20 end_for; 21 22 for i from 1 to n do 23 r[i]:=_if(l[i]=0,"F","T"); 24 end_for; 25 26 rf:=_if(simplify(f,logic),"T","F"); 27 28 print(Unquoted,r[i]$hold(i)=1..n,rf); 29 end_for; 30 end_proc:Some points here: the value args(0) in lines 4 and 8 gives the number of arguments; the expr2text function in line 9 simply returns a string version of a given expression; the error statement in line 4 immediately exits the procedure; the _if command (lines 23 and 26) is a functional form of the standard if statement. The rest of the program simply lists all possible truth values for the variables (this is done in lines 14 to 20), and prints them out, along with the value obtained when those truth values are substituted into the function.
This program may be considered as skeletal only; for example, it does no type checking.
There are several ways of obtaining information about MuPAD: through the extensive on-line help facility, or from published articles.
A few MuPAD books are currently available, but I haven't seen one. The on-line documentation is excellent. It exists in two forms: plain ASCII (for use with MuPAD in terminal mode); and dvi with hyperlinks, when using MuPAD under X.
For ASCII, the help commands are obtained with a question mark:
will provide a few screens of information about <command>. Notice that this is the only MuPAD command which doesn't require a terminating colon or semicolon. The amount of documentation varies; but usually includes a basic description, some examples, and a list of related commands. Some help files are very large indeed; others very small. For example
>> ?stats::medianis short; it basically just tells you that this command returns the median of a list of values. However
>> ?Dom::Matrixis very long, with a detailed discussion about creation of matrices, and operations defined for matrices.
Information about a MuPAD library can be obtained with the info command; for example
provides a list of all commands in the numlib library. You can also use
>> ?numlibto obtain a brief description of all of numlib's commands.
You can see the MuPAD programs which define a function with the use of expose. Again, programs vary greatly in length. For example
returns a short function defined by a six-line program, but
>> expose(D)returns a 164-line program. You can also use op to obtain information; again the amount given varies;
>> op(Dom::Matrix);returns all 1482 lines of the MuPAD program defining matrices.
The documentation for xmupad is provided in the form of a dvi file of the manual, with lots of hyperlinks. The manual can actually be read independently of MuPAD with the hypage command. As with the commands for starting MuPAD, this is a call to a shell script. However, hypage is started automatically with xmupad.
All the relevant documentation is provided in the form of hyTeX dvi files; that is, dvi files with embedded hyperlinks. If you are used to TeX and dvi viewers, this approach will seem very sensible: the mathematics is superbly typeset, as you'd expect, and there are plenty of included graphics. It may seem a bit odd at first to use a book (with all the trimmings: table of contents, chapters, an index) as the paradigm for on-line documentation, but in fact it works very well. And after all, everybody is familiar with the structure of a book, so there is no need to learn the particular exigencies and peculiarities of some new and strange help system.
The amount of information is superb. As well as discussions on all commands and functions, there are extensive chapters on graphics, programming, and debugging, as well as two excellent demos. Moreover, as well as the manual, there are hytex dvi files covering all the MuPAD libraries, as well a handy quick reference.
Once xmupad and hypage are up and running, the help command
will open up the manual at the relevant page. Once inside the manual, you can use the hyperlinks to travel through other similar commands. I find hypage very easy to use. If you have installed MuPAD, you should find this entire article redundant, as everything in it is covered in far greater depth in the manual.
A screen shot of hypage is shown in Figure 4.
However, I have a few niggles with hypage. The main one is that there is no way of changing the font size or page layout. If you reduce the size of the hypage window, for example, the text is not reformatted to fit the available window size, and so you have to use inconvenient scroll bars to view the text. This makes hypage nearly unworkable on a 640x480 VGA screen (such as on my laptop). Moreover, all the text is in the same colour (hyperlinks are given by underlines), which I find a bit dull. There also doesn't seem to be much in the way of keystroke movements. I found three (they aren't listed in the manual): p for previous page; f for forward, and r for return (to the linking page).
On the other hand, with a higher resolution screen, hypage is a delight to use.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide