LIME is an interval toolbox fo Octave containing various interval methods solving various tasks. It is built on Oliver Heimlich's interval package for Octave. It has several goals:

• It is free for noncommercial use.
• It contains various methods solving one problem.
• The methods should be easy to use.
• It should be easy to develop and add new parts.
• It should be easily usable for interval educational purposes.
• The code should be clear and extensively documented (input and output parameters are described, implementation details are described, theorems on which the algorithms are based are cited, history of changes and known errors and future to do’s are listed).
• It does not compete with existing interval toolboxes since their purpose is different.
• Packages are accompanied with examples or at least they are prepared for easy adding of new ones.

Since LIME is a work of a few people it still might contain errors, even though we tried hard to catch most of the flaws. Some known errors are pointed out in .Todo. section of each .m file. There is an effort to make all the methods return verified results. In some cases it is not possible. In some cases verification is omitted to spare compu- tational time. Such situations are documented in .m files if necessary. Most of the current code is implemented by Jaroslav Horáček. Some functions were originally implemented by students supervised by David Hartman, Milan Hladík and Jaroslav Horáček (eigenvalues, matrix powers, interval estimations, interval determinants, etc.). Many more methods were written for Matlab and are waiting to be transfered to LIME (parametric interval systems, evaluation of polynomials, nonlinear solver, etc.)

The latest version of LIME can be downloaded from LIME 2.0.

To install it run install.m file. The only action it executes is adding the LIME directories into Octave PATH variable. To make LIME work, one needs to have Octave Interval package installed. De- tailed information, how to do that is provided at https://octave.sourceforge.io/interval/package_doc/index.html

For a better logical structure LIME is divided into several parts, we call them packages. Each package is contained in a unique folder. It further contains three subfolders. The first is doc which contains the .html documentation of the package (every package has standalone documentation). The second folder is test that can contain examples corresponding to the package. For example in package ils, the folder test contains a function returning the example of interval linear system according to a given keyword. The origin of examples is referenced. The third is develop which contains functions under development. The current packages are:

• imat - functions related to interval matrices,
• ils - methods connected to (square) interval linear systems,
• oils - methods connected to overdetermined interval linear systems,
• pils - parametric interval linear systems,
• inls - nonlinear systems,
• idet - methods for computing determinants of interval matrices,
• iest - interval data estimations and regressions,
• ieig - eigenvalues of (symmetric) interval matrices,
• iviz - methods for visualizations of intervals,
• useful - various methods that can be helpful,
• ocdoc - our minimalistic HTML documentation system.

OcDoc is our own light-weight documentation system connected to (not only) LIME. To generate an .html docu- mentation, go to a desired folder using the command cd in the Octave command line. Then simply call ocdoc. The function searches the current folder for .m files and for each such a file it generates an .html file containing documentation. It also generates a common .html index file for the whole folder. This way each package can be documented separately. To make OcDoc work it is necessary to keep the prescribed format of documentation in each .m file. A template .m file with the documentation structure is attached in the doc package. Even though, it is demanding to fully keep the structure of the file, it is favorable to do so, at least for the sake of future users. The documentation comments contain the following blocks:

• .Author. - name of the author(s),
• .Input parameters. - description of input parameters,
• .Output parameters. - description of output parameters,
• .Implementation details. - explanation of tricky details with references to papers and literature,
• .History. - history of changes,
• .Todo. - known mistakes, errors, future to do’s and improvements.

To get a basic idea how each file is structured, there are prepared empty template files in the folder ocdoc. LIME is divided into packages. Each package has its distinct functionality. Al- though, for some functions it might be arguable where they should be placed. If new functions are of common special functionality are designed, then a new package (folder) is recommended to be created. Remember, that the OcDoc documentation tool creates an .html documentation for each file in a given folder. Functions have a simple naming convention – the name is composed using lower case abbreviations to describe its functionality. No upper case, no dashes, no hyphens are used. The first part of a function name usually consists of the name of the package the function comes from – ilsgeenc (comes from the package ils), imatinv (comes from the package imat). Then the rest of the function name is composed of function- ality specification (e.g., norm for a function computing a norm, hull for a function computing the hull) – imatnorm, idethull. Also the specification of implementation of a function is usually added – ilsjacobienc, ilshbrenc. We remind again, that in order to make the automatic documentation work, the structure of the file must be kept. Here we add some more recommendations:

• Methods do not always succeed. To indicate the state of the result we use the output variable state. We use short (mostly three-letter) string flags. The most common flags are ’vec’ - a finite vector or scalar is returned, ’sin’ - possible singularity occurred, ’zer’ – zero division occurred or pivot contains zero, ’inf’ - infinite result returned, ’exc’ - maximum number of iterations exceeded, ’emp’ - empty solution returned, 'unk' - unknown result. For flags that can be returned by a given method see its .m file or documentation.
• Methods do not always return verified results. We use the output variable ver to indicate verified result. The value 1 means verification, the value 0 means the opposite.
• To indicate that a variable is an interval variable we use the prefix i. Hence ix (iA) is an interval vector (matrix).
• Most of the interval methods work only for interval input, when they are to be used for a real input, it must be intervalized first. It is a responsibility of a user to properly handle that (simply calling the Octave Interval function infsupdec on a real input might not be sufficient).
• If a method is implemented that has similar functionality to some existing method, first see its input and return parameters to make it consistent for other methods that can possibly use this method too.

Here is an example of a function definition satisfying the above recommendations: [ix, state, it] = ilskrawczykenc(iA, ib, e, maxit, ioldx)