Here we won't speak about really mighty features like defining own rules or object types; they are described elsewhere. Instead we'll start with tiny, easy to use tools of fine-tuning.

You can tune many aspects of polymake behavior by changing values of numerous variables which are dedicated for keeping user-visible settings. In the following these variables are called with their polymake nickname custom variable (which actually has been borrowed from the xemacs terminology). The definitions of custom variables are scattered over dozens of rule files; fortunately, polymake offers two ways of accessing them in a more systematic and comfortable manner.

1. All definitions are repeated in a text file residing in your home directory: ~/.polymake/customize.pl . You are invited to load it in your favorite text editor and study its contents. The variables are sorted there first by applications, then by package names. Most of them will appear as deactivated (that is, the lines start with # which is the perl fashion of making comments to programs). This means, the default values assigned to them somewhere in the polymake source code are in effect. If you want to change them, simply remove the # sign and fill in your desired value. By the way, the color values don't need to be entered in numerical RGB notation; any color name listed in the system color list addressed in $Visual::Color::RGBtxt_path can be used instead.

   Some variable definitions appear accompanied by a preceding line of the form ARCH('xyz') . These are special in that they are dynamically set by auto-configuration routines lurking in some rule files, and therefore potentially dependent on the computer architecture. (Recall that you may use polymake on alternating computer platforms having different paths to programs etc.) The preferred way of changing these variables is to use the reconfigure command as described below, because with some of them additional consistency checks may be associated. But in many cases they can be easily edited as well.

   A few variables are stored in a different file: ~/.polymake/prefer.pl . They are separated from the rest because they don't belong to any application but rather control the universal facilities like history editing in the interactive shell or locating extensions. When specifying various search paths, you may use ~ as an abbreviation for your home directory; other environment variables can be referred as $ENV{name}

   Please remember that you shouldn't edit any of these files as long as a polymake process is running anywhere under your account. Sometimes polymake needs to store some changes there on its own behalf, but this happens immediately before the exit; so either your or polymake's changes will definitely be lost.

2. There are two interactive commands manipulating custom variables:

   set_custom $name=value;

   set_custom @name=(value, ...);

   set_custom %name=(key => value, ...);

   set_custom $name{key}=value;

   set a new value of a scalar, an array, a hash map, or a single value therein

   reset_custom $name;

   reset_custom @name;

   reset_custom %name;

   reset_custom $name{key};

   restore the default value

   Both commands come into effect immediately, but also mark the variable as changed, so that the new value will also appear in your personal customization file after the session end. You can also change the custom variables for the rest of current session only, without updating the file – by a plain assignment. If you want to change some value temporarily, just to influence the evaluation of the next expression, write the local keyword instead of set_custom. (It's not polymake's black magic, just normal perl operator.)

There are two custom variables related to applications. The list @start_applications contains names of all applications to be loaded at the very beginning of the interactive session (although the process of loading applications is totally transparent to you, having loaded your favorites in advance avoids annoying delays during the session). The variable $default_application names the application to be made current at the beginning of the session. Until you change this, it will be polytope for its undisputed merits as the oldest and most prominent application in polymake.

Preferences are lists of choice of different tools capable of performing the same task. When polymake can't make a choice based on objective criteria, it consults the preference lists and takes the tool listed as first. For example, there are several programs capable of drawing a 3-d polytope: javaview, povray, geomview, etc. Another example is the convex hull computation for which up to five different algorithms (depending on the coordinate type) come into consideration. The sensible choice between them can't be made based on some quantitative estimates; instead, your intuition and, sometimes, personal taste must take over the leadership.

As with custom variables, polymake offers two ways of handling the preferences:

1. Manually editing the file ~/.polymake/prefer.pl . The preferences are stored in the last section of this file, grouped by applications. What you see there are exact copies of prefer commands as they appear in the polymake rules. Modify them at your taste. They have the same syntax as the interactive commands described below.

2. Calling interactive commands:

   prefer "label";

   declare some tool to be the preferred one for any tasks it may perform. For example, saying prefer "jreality"; instructs polymake to call jReality to display any kind of 2-d, 3-d, and 4-d drawings related to polytopes, as well as graphs visualized with spring embedding model. You can specify your wishes more precisely, though: saying prefer "graphviz.graph"; makes the neato program from the graphviz package the default tool for visualizing graphs, letting jReality be responsible for all the rest.

   prefer "*.task label1, label2 ...";

   establish a specific order of preferred tools for special task. For example, a command prefer "*.convex_hull cdd, lrs, beneath_beyond"; directs polymake to always try the cdd convex hull computation first; if it fails, the lrs algorithm will be applied; if both fail, then beneath_beyond, and as the last resort anything else without specific order.

   reset_preference "label";

   restore the settings to the pristine state. It accepts a tool name or a wildcard expression as its argument and restores the effect of any matching prefer command encountered in the rule files. The most radical form reset_preference "*"; forgets any preferences you've ever changed and restores the “factory settings”.

   Both commands come immediately into effect; before exiting the interactive session the changes will be stored in your preference file.

   prefer_now "labels";

   does the same as prefer, but restores the previous setting as soon as the current input is completely evaluated. No persistent changes are made. This command can be seen as the local modification of prefer (standard perl does not allow to apply local to anything but variable assignments).

   show_preferences;

   display all active preferences in the current application. If you want to find out all tools involved into the preference mechanics, including inactive ones, use the TAB completion in prefer command or browse the help system starting at the topic '/preferences' .

Remark: the location of the configuration files can be changed from its default value ~/.polymake by setting an environment variable POLYMAKE_USER_DIR=/other/location, or overridden temporarily just for one session with a command-line option --config-path.