Message Boards Message Boards


Turning functions into programs and distributing them

Posted 9 years ago
7 Replies
5 Total Likes

I have written many, >100, functions for use in my day to day engineering design work. These mostly make use of a units package I have also written, and the Symbolise package. Many of the functions also call other functions. To date, I have put most of these functions into a single notebook and load and run this at the start of a new Notebook. This is tedious and a bit slow. Is there a better way?

Should I be splitting these functions into groups and installing them as packages? If so, can I get them to call other packages eg. the units one and does it matter if I get multiple calls to that package?

Finally, I wish to distribute some of the functions as stand alone programs, either as CDFs, if user inputted data is not required, or else with Player Pro. How do I then manage packages?

Any guidance will be gratefully received.

POSTED BY: malcolm woodruff
7 Replies

It's really quite easy.

1) Put your project, study subject or application in the \ $UserBaseDirectory/Applications folder. Just make a folder there with a name such as MyApplication (but in practice something more specific). You could add subsidiary folders such as DevelopmentNotebooks, DistributionNotebooks, *et cetera*. I find it very difficult to convince people to put their projects there! They have all kinds of spurious reasons to go somewhere else. "WRI puts some of their packages there and I don't want to mix my feeble efforts up with their packages." They say that because some of the WRI packages are mixed in on the Installed Add-Ons documentation page. But WRI packages are not in that location. The \$UserBaseDirectory/Applications is your place and you can put anything you want there. You initially don't even have to have any packages in your application. The point is that when you get to adding packages, style sheets, palettes and documentation this is the place where Mathematica will look for ALL of these items. If you zip up your application, send it to a friend and they unzip it into their \$UserBaseDirectory/Applications folder everything will automatically work. They will be able to access your application from anywhere. They won't have to use SetDirectory, or put their notebook in the same folder as the packages. Your style sheets and palettes will show up on their menus. If you add auxiliary files, say data files, to your projects, your routines will know exactly where to look for them. Please, put your project there. Try it out and see how smoothly it works.

2) A fully developed application would have a file structure that looked like this:

MyApplication (which is the application name)
            palettes associated with MyApplication...
            stylesheets associated with MyApplication...
      init.m - initialization for MyApplication

Initially you might have nothing but DevelopmentNotebooks.

3) This is how I usually develop package routines. (Others may find a different path more convenient.) Routines usually arise when I'm working on some material within a study or development notebook. I test it out with the current material. I usually add usage messages, SyntaxInformation and any other items that go with the routine. Then I move the routine to a Routines section at the top of the notebook. I call this "package purgatory" and keep it there until I've used it on more examples. The first draft is quite often not sufficient. When I'm reasonably satisfied I'll move it to the package itself - "package heaven". If I have to do further revision I might do it in the package, or change the package Code cell to an Input cell and go back to the notebook to revise.

4) You application would be loaded with the command:

<< MyApplication`

In this case, Mathematica will evaluate the init.m file in the Kernel folder. This file should contain the statements:


The BeginPackage statements in the packages reflect the folder structure. The package with the name package1.m would have the BeginPackage statement:

BeginPackage["MyApplication`package1`", {...}]

5) You can create a package file by creating a package1.nb file and then changing the "nb" to "m". Package files are similar to Notebook files in that they can have Titles, Sections, Subsections,Text and other cell types. I strongly recommend using the sectional organization and separate cells for the various statements. The operational part of the package is contained in Code cells. You can inactivate routines by changing them to Input cells.

Then, when a routine is ready for package heaven, just copy the usage statement into the Public section and the rest into the Private section.

Following this format, you can slowly build up your work into a very nice application. You don't have to do everything at once. You have a structure that will accommodate the development of your application and your own increasing skills at application development.

I face the same challenge - packaging initially for my own use, eventually for use by others. I look forward to following this thread.

POSTED BY: Mark Tuttle

Thank you! I will try this and see how I get on. I do have Mathematica 10 so no longer have Workbench. I did look at it when it first came out in an earlier version but found I got on better directly in a Notebook. I will look at it again when the new version appears. I think I am like a good many engineers that come to Mathematica. I started using it as a scratch pad for presenting calculations and then writing my own functions as needed, as I became more proficient at this I have become more ambitious and have ended up writing many programs, some of which are quite complex. Now others want to make use of them and I need to sort out a proper and more logical way of organising and distributing them. Hence the question. Thank you again for your help.

POSTED BY: malcolm woodruff

Write Applications!

If you look in your copy of Presentations you will find an essay on "Writing Applications" that lays out the entire structure. I believe it is the way WRI designed packages to work.

Packages will generally be part of an application. That is the place to put your routines. If later you obtain Workbench (and when is WRI going to provide a Workbench for Version 10!) you could add documentation pages, Anyway, you can build up an application over time but it's very useful to start with the right structure. An application can also contain extra folders and notebooks related to the application. Also palettes and style sheets. It is a good way to organize and preserve work.

You can also produce versions of you applications with packages, perhaps encoding the packages, that also contain style sheets but eliminating documentation, and send these to people who have the free CDF player. They can install them in their CDF player and then read your CDF files that use your packages.

It would be very nice if WRI provided a CDFUserBaseDirectory that paralleled UserBaseDirectory. This would be a better place to put packages associated to CDF files.

Posted 9 years ago

To which Presentations are you referring, David?

POSTED BY: David Keith

Sorry, it's the one that I sell for $50 from the Kagi store with links from my web site. It's quite large and oriented to writing literate notebooks with custom graphics, custom tables and custom dynamics. There are many examples and essays so it is a bit like a book.

Posted 9 years ago

Thanks, David. It sounds very useful.

POSTED BY: David Keith
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
or Discard

Group Abstract Group Abstract