Preface

Table of Contents
1. Outline
2. Other Formats of sci-BOT
3. Packed examples
4. Typographic conventions
5. Scilab Release History by Enrico Segre
6. Contributions
7. Acknowledgments

Often we encounter technical problems that we have to solve, to overcome somehow, or just to work around. After having mastered the difficulty, we gladly add it to the knowledge-base in our mind, but from a certain level of difficulty we start to make notes in one form or the other. These notes then serve for later reference. A collection of related notes can be exploited to gain further insight in the class of problems it describes. Last but not least one can get ambitious to fill the holes of knowledge that an existing set of notes leaves unanswered.

 

An expert in a particular computer language is really an expert in the work-arounds necessary to use this language to perform useful work. An ideal computer language would do exactly what it was told simply from reading a specification. In the absence of a specification, it would ask enough questions to produce such a specification, then it would generate the code necessary to perform the specified functions.

...

Even C has its shortcomings which have to be handled with assembly language extensions. A Master Carpenter has many tools and is expert with most of them. If you only know how to use a hammer, every problem begins to look like a nail. Stay away from that trap. It bytes (sic).

 
--Richard B. Johnson  

This is the story of sci-BOT paraphrased. It started with bits of experience gathered in our heads and scattered e-mail correspondence. After more and more e-mails piled up, telling the same old stories, one of the authors (lvd) decided to compile the problems and their solutions into a convenient format. Perl's plain old documentation, POD, was chosen for its simplicity paired with a multitude of output formats. However, after 2000+ lines it became clear that POD was missing a feature that would be needed as sci-BOT grows bigger: cross references. A more powerful documentation format and the associated tools had to be found. A two week web research resulted in one clear winner: DocBook. The downside of the necessary switch of formats was that the previous work done with POD had to be converted into DocBook. Daytime work plus adding new material to sci-BOT plus converting the old work into the new format is too much for a single volunteer. So, a second idiotM-DELauthor was searched and found (cls). His ten years of experience with the TeX/LaTeX typesetting system, his accuracy, and his intensity with which he attacks any obstacle made him the ideal choice for this madnessM-DELproject.

1. Outline

We open up talking about some of the most common syntactic pitfalls when using Scilab in Chapter 2. Finding that some of these syntax problems can be avoided with a clear programming style, the next chapter, Chapter 3, deals with coding issues. In Chapter 4 we then focus on the parts of Scilab that are not well documented, and therefore widely remain unknown spots. For many users not only enjoy the nice user interface of Scilab, but demand high performance from the interpreter the massive Chapter 6 about performance issues covers these needs. It begins by introducing techniques suitable at a high level like vectorization which do not require low level programming and then dives down into the extension of Scilab by compiled routines. This is a vast field by itself. Therefore we have devoted a full chapter, Chapter 7, to the low level API. sci-BOT closes with Chapter 8 containing remarks on compiling and debugging as well as comments on the supplied documentation and available web pages. All of the programming snippets that belong to longer examples which do not fit in the main text have been gathered in Chapter 10, where they show up in full length.

At the end of the document we have put two appendices with the GNU Free Documentation License, and the GNU Public License, a bibliography, and an index.