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 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 open.
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 plus lines it became clear that POD was missing a feature that would be needed more and more as sci-BOT would grow bigger: cross references. A more powerful documentation format and the associated tools had to be found. A two week web research resulted in one 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.
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. We then focus on the parts of Scilab that are not well documented and therefore widely remain Chapter 4. A very brief discussion, Chapter 5, about the graphical capabilities follows. For many users not only enjoy Scilab's nice user interface but demand high performance from the interpreter the massive chapter, 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 the dives down into the extension of Scilab by compiled routines. This is a vast field by itself. Therefore we devoted a full chapter, Chapter 7, to Scilab's 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.