home / intro / faq / tutorial / manual / models / download / people / about
|
|
|
|
|
home / intro / faq / tutorial / manual / models / download / people / about |
||
| frequently asked questions |
|
Currently, little b is limited to preparation of ODE (ordinary differential equation) models of biochemical systems. Our initial deployment creates Matlab code which performs numerical integration. We're working on an SBML converter, which will enable models prepared in b to be exported to a wide variety of software platforms.
No. But, someone should build one.
No. Little b builds mathematical models. A separate program is required for a particular type of analysis, such as simulation. Currently, functions are provided to convert b models to MatLab code (and soon to SBML). However, since b is embedded in LISP, it is possible for functions to be written that enable simulation within the b/LISP programming environment.
Currently, the only interface to little b is text. However, it's possible to build models by just copying and pasting code. We'll put a few examples of this in the tutorial which is under development.
Little b was designed to enable reuse of existing approaches. For small models which aren't intended for sharing and which require development of new mathematical representation techniques, you are better off using full-featured mathematics programming environments. In b, a little up front work is required to describe a new modeling technique in terms of how relationships between objects should be translated to mathematics. Once this is done, however, you will be able to write models in terms of objects and relations rather than raw mathematics, and to reuse and share the new technique.
Little b and XML-based languages, like SBML, are complementary solutions to the problem of model building and sharing. SBML is (and must be) developed through a process of consensus amongst the community. This is an important activity, which has the benefits and disadvantages that come with getting a group of people to come to agreement. Also, XML is language-neutral which makes it a good choice for transferring data between programs written in different languages. Because b is based in LISP, reading models from other software packages requires a language neutral format like SBML. So b will need to interoperate with SBML, and should be viewed (once we get the converter done!) as another part of the SBML software community.
Like SBML, little b is also a language for model sharing, and has some of the same goals, but b really occupies a different niche. The main difference is that it is also a programming environment. An analogous distinction in the world of mathematics are programming language environments like Matlab and Mathematica versus mathematics exchange formats, like MathML. B has mechansims for computing symbolic mathematics; describing, automatically naming, and reasoning over objects; a much terser syntax than XML that makes it easy to read, write and interpret; and has a number of other facilities designed to help modelers and programmers as they develop models and the mechanisms for sharing models. These features make little b good for rapidly prototyping new solutions.
Little b is a powerful meta-language for describing new modeling techniques as well as being a model sharing language. For example, we are developing a component for describing molecular scaffolds, based on a particular set of mathematical assumptions. With this component, a biologist can describe a scaffold, drop it into her model, and the language infrastructure will take care of wiring the mathematics correctly. Not everyone has to agree that this is the only way to describe scaffolds - it may be useful only when a particular set of assumptions can be made, for example. So it is important in this case that we can formally describe the new approach (and make it shareable) without having to alter the core language specification (as must be done for SBML). This also relieves programmers from having to write potentially complex code to support each new modeling approach. It is unlikely that the SBML community will have the time to review, document and support every new idea that is reported; b fills this niche - it enables a light-weight specification/development/sharing cycle.
Another important distinguishing capability of b is compositional model building - that is, the ability to compose a model from pre-existing parts. In b implicit species and reactions are automatically calculated, and mathematics is automatically constructed depending on what mechanistic and kinetic assumptions have been chosen. Although proposals for some of these ideas have been put forward for SBML, an official specification has not yet been decided upon. Part of the difficulty (besides the problem being a tough one) is that it is not clear which is the "correct" representation - often there are different ones, each suitable to different problems and styles of modeling. Little b supports a few different interoperable methods - and you are free to invent (and share) your own, as well as build on the existing mechanisms.
SBML and CellML are two well-known XML-based model exchange formats. SBML in particular enjoys support by a wide array of software packages. It was originally developed to enable exchange of monolithic models between software programs. XML, a data exchange format closely related to HTML, was a natural format for this purpose, since it is a widely accepted standard. XML is different from languages like C, Perl, LISP, Prolog, Python, etc. as it only describes data, not "code" (instructions which cause a computer to do something). What a program should do with data is undefined by the XML model. A positive aspect of this is that, with XML, we don't have to worry about computer security issues arising from malicious code. However, the expressive power of XML is limited by its interpretion.
In SBML and CellML, the "correct" interpretation of the data is specified in documents written in natural (human) language. Software programmers must read the specification documents and convert the requirements into code (in C, LISP, Java, etc.) for reading SBML or CellML. Because SBML/CellML are not intended to be powerful "Turing-complete" languages like LISP or C (in part for reasons desribed above), as new modeling approaches are added to the specification, new code must be written for each software platform which reads SBML. One way the SBML community has coped with the cascade of programming requirements implied by this approach is to create libraries for reading SBML in different programming languages.
In little b, by contrast, the "specifications" are written directly in b, rather than English. B is built from and extends LISP, an unusual language that purposefully blurs the line between code and data. The basic LISP data structure (the list) can be used to describe XML-like data trees as well as code which causes a computer to perform calculations. In b this makes it possible to describe, share and use a new modeling technique all within the same language, and with a minimum of syntactic overhead. The disadvantages of this approach are code-security issues (currently unaddressed in LISP) and the loss of language and platform neutrality. We think there are complementary roles for b and XML, and that it will be advantageous to translate between them.
One answer is that LISP is particularly good for manipulating symbolic expressions such as those required to describe mathematical models. Every language has its particular strengths. LISP is very good at handling problems of high complexity. Often problems which are too complex to code or even impossible conceive an answer to in other languages, yield elegant solutions when LISP is used.
Two features - ordinary macros and reader macros - make LISP an ideal language development laboratory. They make it possible to extend and modify the behavior of the LISP interpreter/compiler. This makes it possible to create an embedded language which has the desired properties while retaining the functionality of LISP and editing/debugging tools.
In fact, it's a common coding style in LISP is to define a sub-language which handles a particular problem domain. Macros are a powerful feature unique to LISP. Much of the top-level syntax of LISP itself, such as for definition of functions or classes - syntax which is hard-coded into the compilers and interpreters of other languages - are written as macros in LISP. Macros make it possible to write expressions with entirely new semantics. For example, imagine writing your own version of a syntax for defining classes in Java, C++ or C#, or extending a non-object oriented language like C, Fortran or Pascal with object-oriented features. It's difficult to conceive how to do this without having to rewrite the entire underlying compiler or interpreter. However, LISP makes such things possible. In fact, the object-oriented system in Common LISP was defined using ordinary LISP macros. That means a LISP programmer is free to invent entirely new programming constructs within the language. This capability was very important in writing little b.
Another amazing LISP capability is the ability to modify the reader. Reader macros change the way the language responds when a particular character is read, and a number of characters are purposefully left undefined in the Common LISP standard for precisely this purpose. For instance, in b, in order to write terse expressions, we provide interpretations for the square ([]) and curly braces ({}). This is not possible in other mainstream languages.
top1. A global database of objects (based on CLOS).
2. A rule system which enables code to be run when objects matching some criteria are detected. This capability is based on an efficient pattern-matching algorithm called RETE. The current implementation uses the open source LISA engine.
3. Top-level macros for defining object classes and rules: defcon, defrule, defprop, define and defield.
4. LISP character syntax is extended with reader-macros: square brackets are used ([]) to create objects, curly braces ({}) are used for infix expressions (which writing math easier), and the dot (.) is used to access fields of an object (in a way that does not interfere with its use as the "consing dot").
5. An extensible symbolic math subsystem for representation of units, dimensions, and simple polynomial arithmetic.
6. A system for automatically deriving names from top-level symbols.
7. The printed representation of many types of objects is in the form of code for creating those objects.
Those of you who asked "why lisp?" may be thinking this. Contrary to popular belief, programming in LISP does not necessarily require one to master the techniques of recursive programming. This misconception is largely due to the fact that teaching of Scheme, a minimalist dialect of LISP, has often emphasized the use of recursive functions in place of procedural loops1. Common LISP (on which b is based) is more widely used in industry and sports a variety of powerful and easy to use looping constructs, and even goto statements.
1Scheme does support looping - thanks to Marco Antoniotti for correcting me on this.
July 26, 2005 - Aneil Mallavarapu