Extending/Modifying KnotTheory`

From Knot Atlas
Revision as of 22:23, 13 June 2007 by 125.180.110.161 (talk)
Jump to navigationJump to search


Anybody is welcome, indeed encouraged, to fix, modify or extend the package KnotTheory` to the benefit of everybody else. This note explains how this can be done and outlines some of the conventions used within KnotTheory`.

Seeing the sources

The source files for KnotTheory` are kept in a Subversion repository whose overall directory structure is as follows:

http://katlas.math.toronto.edu/svn/KnotTheory/...

  • trunk/... contains the current "working" version of the package.
    • KnotTheory/... is an unpacked version of the whole package, as seen by users.
    • src/... contains the individual mathematica "modules" that are glued together to make KnotTheory/init.m, the main executable of KnotTheory`.
  • branches/... contains development versions of certain new features that are not yet included in the package.
  • tags/...
    • stable/... contains the last "stable" version of the package. It is a snapshot of the trunk/ directory, at some previous moment in time. "Stable" doesn't necessarily mean any great degree of testing has gone on; it just means that the most recently introduced bugs in the trunk haven't been included. The downloadable package is generated from this directory.

Writing Your Extension

Submitting Your Extension

KnotTheory` is a computer program written in an unrestricted language. Meaning that a vicious programmer could use it to do harmful things to the computer running it. Therefore unlike much of the rest of the Knot Atlas, it can be modified directly only by the administrators of this site. If you aren't one, email your extension/modification to Dror. Dror will read through it quickly to confirm that it's not malicious and doesn't do anything obviously wrong and post it in the Setup section of this manual. Thanks!

Lessons learnt from integrating LinKnot`

In February 2006, Radmila, Dror and Scott spent a few days making LinKnot` and KnotTheory` play nicely together. In the end, we had at least partially achieved two of our goals:

  1. Allowing the concurrent usage of KnotTheory` with LinKnot`, so that users of LinKnot` can access the databases and algorithms available in KnotTheory`, while maintaining familiar notations and function names.
  2. Making the functionality of LinKnot` transparently available to users of KnotTheory` (with function names and data conventions consistent with KnotTheory`).

These two goals seem to be a reasonable model for integrating a pair of complementary Mathematica packages; former users of each expect not much to change, but simply to have extra functionality. It's also a reasonable 'minimal' model, in that only 'compatibility layers' are written, leaving the original packages (mostly) unchanged.

Loading side by side

Our first goal was simply to be able to load KnotTheory` and LinKnot` side by side. Initially, we were prevented by two different problems. Firstly, each package unintentionally introduced symbols into the Global` Mathematica context. Secondly, each package expected that the current working directory always be the home of the package; expectations unsatisfiable simultaneously!

Global` symbols

Fixing leakages from KnotTheory` wasn't too hard; just load KnotTheory` in a fresh Mathematica session, then issue the command Names["Global`*"]. There shouldn't be much there, and it's mostly a matter of tracking down where the stray symbols have been introduced. If you don't understand Mathematica's (utterly ugly) system of contexts, you'll start to get the hang of it while doing this!

Leakages from LinKnot` were much more serious, as several subpackages were loaded directly into the Global` context (the authors of K2K didn't follow the usual Mathematica package conventions).

At this point we discovered the first of several painful problems associated with symbols in contexts which aren't currently on the context path, namely that conversions to and from strings (with ToString and ToExpression) are very dangerous. These happen 'at runtime', so the context path could be quite arbitrary (that is, having been modified by other packages or users since the package was loaded), rather than at the moment the package is loaded. It is often necessary to wrap calls to ToExpression with code which temporarily resets the context path. Seaching for ToExpression in the LinKnot sources should find examples of this.

Current working directory

Unfortunately many parts of the K2K package rely on the current working directory being the LinKnot` installation directory. This causes all sorts of problems; users should be able to change the current working directory arbitrarily. Even worse, there are still some bugs in KnotTheory` where certain things don't work if the current working directory isn't set to the KnotTheory` installation directory!

We used two techniques to get around this. First, the KTtoLinKnot subpackage tries to work out the LinKnot` installation directory, using the mnemonic

LinKnotDirectory[]=
        DirectoryName[
          File/.Flatten[
              FileInformation[ToFileName[#,"LinKnots.m"]]