The BBC has an interesting news report, Warning sounded on web's future, on the worries of Tim Berners-Lee about the spreading of disinformation using the web. The article also touches on other related topics such as extending the reach of the web and improving the web's usability.

Regarding the problem of publishing insincere or unfounded information on the web, Berners-Lee cites a recent campaign started because of the activation of the Large Hadron Collider. Specifically, some groups used the web for communicate invalid beliefs about the world being destroyed by effect of the LHC. This use of the web is, in first instance, unethical. Further, it may transmit fears, and additionally, the information posted by such groups has no scientific grounds. This a typical example of misusing a system.

This kind of problem arises because of the web's intrinsic nature. The web is a different system... a system which is now inevitably linked to the behavior and trends of human society. The web is an open and complex system. It's open because we can add as much information as we want, and it's complex because it's composed of a huge amount of producers and consumers of information, and their interactions. There is other factor that shapes the web complexity: evolution

The web changes at very high rates. The web's technologies an content change so quickly, that it's impossible for any person to assimilate all this evolution. After all, the user only wants to open her browser and read the news. Typically, she is interested neither in the technical details behind the publishing platform, nor in the path followed by the information until arriving to the final form on the online media. There is a tool the user recurs to in order to fight complexity: trust.

The user of the web has some expectations about her relationship with information: veracity, reliability, availability and security. However, these expectations are sometimes hard to meet in a system so open and complex such as the web. We are relatively accustomed to reading about privacy and copyright issues on the web. For example, the September 2008 Scientific American is a special issue on The Future of Privacy, loaded with plenty of excellent articles.

Disruption of privacy and copyright certainly undermines trust. Nevertheless, the web has too much power over the whole world. It can modify the behavior of social groups. Our modern dependence on the web makes us very vulnerable to the plots of groups and interested corporations. Therefore, structures for identifying trustworthiness of a site may be desirable. But I believe that the web itself tends to its own well-being. Precisely, its complexity and openness makes it very resilient to attacks and fake information. The web empowers the people and, in  turn, is empowered by people. Ultimately, fake data will be identified and disregarded. It's the same idea behind Wikipedia's trustworthiness.

Finally, there are other interesting challenges identified by Berners-Lee. First, we have to look at extensions of the current web infrastructure in order to improve access to information (easier and broader access). We also have to protect the web of groups or corporations pretending to abuse the web to meet their egoist goals. We have to care for the web because, after all, our future and evolution is inextricably linked to the web's.

1. I want to know how to declare a const variable in one file and access it from other files? (C++) by Ricardo Orozco (Venezuela).

   It's a fairly basic question, and reveals that you have to study more C++. What you want is to define a const variable at global scope. Unlike non-const variables (which are extern by default), const variables are local to the file in which they are defined. Therefore, you cannot access them from other files unless you specify that the variable is extern.

   For instance, if you specify extern when defining the variable

   bufferSize in file1.ccextern const int bufferSize = 512;

   you can access bufferSize from any other file, say, file2.cc

   extern const int bufferSize; // we are using bufferSize from file1.cc

2. I'm just starting to study speech synthesis, and I'm faced with the calculus of resonances in an uniform acoustic tube. The glottal end is closed, but the mouth is open. Could you expand on this? by Bakuman.

   This is the configuration you are studying:

   

   The acoustic tube is uniform, and its length is L. The glottis, located at x=-L, is closed (infinite impedance) and the mouth, located at x=0, is open (impedance zero). Now, pressure variation p(x) along this uniform acoustic tube is expressed as:

   

   where f represents frequency in Hz, and c is the speed of sound: at 37° C.

   According to the boundary conditions (the impedances at both ends), the solution is:

   

   where is the peak in sound pressure. On the other hand, we have a relation between pressure and volume velocity

   

   is a constant representing the tube's area. Now, volume velocity can be expressed as

   

   where equals the average atmospheric density ( at 37°C).

   As U(−L) = 0, resonances Fn of the acoustic tube are

   

   where n=1, 2, 3... And that's it. We can see that the area function does not affect the location of resonances. Finally, remember that, in average, the male oral tract has a length of 16.9 cm, and the female tract has an average length of 14.1 cm.

3. What's an stub? by Dani Hoffmann (Colombia).

   It really, really depends on the context. Your question is too ambiguous. A Stub may even be a relative of the Danish poet Ambrosius Stub. After all, code is poetry.

   In computing, I know of 4 contexts where the word stub has a well-established meaning:

   1. Web Sites: A stub is a web page in progress, i.e., a page which provides minimal information and is intended for later development. For instance, a Wikipedia stub is a short article in need of expansion.
   2. Coding: During development, we sometimes use a "skeleton" function (or procedure, or method) to simulate some intended (but not yet implemented) functionality. For instance, the function may stand in for a complex algorithm to be developed later, or simulate a procedure running on a remote host. Such placeholder function is called a stub function. Stub functions come in handy for quick prototyping and testing.
   3. Distributed Systems: In distributed systems, a service interface defines the services available to programs. These services are distributed among several networked machines. In distributed systems, a program in machine A may request a service by calling a procedure. However, the procedure may be offered by a remote host, say, machine B. Remote Procedure Calls (RPC) are a paradigm of distributed systems aimed at abstracting the communication between hosts in a network. The goal of RPCs is to hide the details of the remote call. The remote call should look like a local one, i.e., the program in machine A would invoke the procedure in machine B as it would invoke a procedure locally. Under the hood, though, it's obvious that we have to transmit information from the client (caller) to the server (callee), and in the other direction. Now, how to hide the fact that we are calling a procedure located in other machine? This is the basic idea of RPCs:
      • In the address space of the client, we represent the server procedure by means of a local procedure called client stub. Likewise, the server is also linked to a server stub, which will receive the message from the client stub.
      • When machine A requests a service which is provided by machine B, a call is made to the client stub (which has the same name as the procedure in B). As the client stub lies in the same address space of the caller, the invocation is handled locally, and the program sees this invocation as a local one. However, the client stub marshalls the received parameters and sends them, throught the network, to the server stub. In turn, the server stub unmarshalls the parameters and perform the call to the real procedure in the server. When the server procedure finishes, results or exception data travels back, from server to client. By the way, marshalling is the process of taking a collection of data items (such as the procedure name and its arguments) and grouping them according to some predefined representation, suitable for transmission over the network. The server should know and conform to this representation in order to unmarshall the received data and recover the transmitted information.

      Albeit conceptually simple, there are some interesting (nasty) problems for implementing RPCs, such as passing pointer arguments (remember that client and server have different address spaces).

   4. Computer Networking: A stub network is a network or part of network with only one communication path to external networks (non-local hosts). For instance, if we connect to our Internet Service Provider using only one router, our local network is a stub network with respect to our provider.

   There is other related context for stubs: in electronics, we identify Stub sections, which are mostly used for impedance matching in transmission lines. But I'm not too familiar with this "stub" meaning.

As always, it was a pleasure to answer your questions. Thank you very much.

I do strongly believe in abstraction being the root of computing (however, you may want to read Is abstraction the key to computing? as a motivation for a different perspective on the role of abstraction in computing). Modern hardware and software systems include a lot of features and perform so many tasks that it is impossible to understand, build and use them without recurring to abstractions. For instance, let's take a look at the CPU: it is the central part of a general purpose computing system, and is also an extremely complex system in itself. Functionally, a CPU is an instruction-crunching device: it processes one instruction after another, following the steps of fetch, decode, execute and writeback (in von Neumann architectures). In other words, the CPU retrieves the instruction from memory, decodes it, executes it, and put the results of the operation back into memory. Further, the CPU has no clue (and actually does not care) about the higher-level semantics of the instruction it may be executing at a specific time. For example, the CPU may be executing an instruction related to a spell-checking task, and a few instructions later it may be executing an instruction related to other task, say, MP3 playing. It only follows orders, and just execute the instruction it is told to execute.

Nowadays, computing systems are expected to do more tasks on behalf of its users. Several tasks must be performed concurrently. As in the previous example, the system might be running the spell-checker and the media player simultaneously. In multiprogrammed systems we can achieve pseudoparallelism by switching (multiplexing) the CPU among all the user's activities (true parallelism is only possible in multi-processor or multi-core systems). Remember that multiprogramming requires the CPU being allocated to each system's task for a period of time and deallocated when some condition is met.

The Process

So far, we've spoken about activities and tasks, comprising a sequence of instructions. Moreover, the CPU will be multiplexed among such tasks in order to execute them in a pseudoparallel fashion. However, in order to to harness such computing power, we cannot think of long sequences of instructions, which may jump from one instruction to another at any time. We require to abstract such processing into some convenient concept or model. That model, the central unit of work of operating systems, is the process. Considering a program or code as a sequence of instructions which implement some algorithm, we can state that

a process is a running instance of a program

Passive and Active Entities

Code does nothing unless it's executed by a CPU. But a process is a program in execution. A web browser being run by an user is a process. A compiler analyzing some input files is a process. Nevertheless, it is very important to realize that a program or raw code is not a process. A program is a passive entity, whereas a process is an active entity, for which the operating system allocates structures for controlling it and handling its resources and control information.

Further details

• Unlike passive entities, processes use resources: CPU time, memory, files and I/O devices. Such resources may be requested at creation time or during the process execution. When the process finishes its task, the operating system should reclaim or retrieve any unused resource.
• Execution of a process is sequential. Instructions are executed one after another, until the process finishes. Moreover, a process may spawn many subprocesses during its execution, by means of some system calls.
• Some processes execute system code (operating system processes) and other processes only execute user code (user processes).
• Among other responsibilities, process management involves:
  • creation and termination of processes,
  • scheduling,
  • suspension and resuming,
  • interprocess communication,
  • synchronization,
  • allocation and freeing of resources,
  • setting and retrieving processes' attributes.

In a forthcoming installment, we'll delve into the finer details of process management.

gettimeofday() is a function for retrieving system time in POSIX-compliant systems. Unlike the time() function, which has a resolution of 1 second, gettimeofday() has a higher resolution: microseconds. Specifically, the prototype of gettimeofday() is:

int gettimeofday (struct timeval *tp, struct timezone *tzp)

The function retrieves the current time expressed as seconds and microseconds since the Epoch, and stores it in the timeval structure pointed to by tp. The struct timeval has the following members:

long int tv_sec: Number of whole seconds of elapsed time.
long int tv_usec: The rest of the elapsed time (a fraction of a second), represented as the number of microseconds.

Thanks to the tv_usec member, we have a resolution of microseconds. It's also important to remember what the Epoch is. The Epoch is just an arbitrary starting date set by the system in order to compute time, i.e., it's a reference or base time. For instance, POSIX-compliant systems measure system time as the number of seconds elapsed since the start of the epoch at 1970-01-01 00:00:00 Z.

On its side, the struct timezone was used to return information about the time zone. However, using this parameter is obsolete (e.g., it has not been and will not be supported by libc or glibc). Therefore, tzp should be a null pointer, else the behavior may be unspecified (check your system's specifications).

gettimeofday() returns 0 for success, or -1 for fail. Simple. Further, this function should be available in sys/time.h. But my friend's installation of MinGW only included the following in sys/time.h:

 
#include <time.h>
 
#ifndef _TIMEVAL_DEFINED /* also in winsock[2].h */
#define _TIMEVAL_DEFINED
struct timeval {
  long tv_sec;
  long tv_usec;
};
#define timerisset(tvp)	 ((tvp)->tv_sec || (tvp)->tv_usec)
#define timercmp(tvp, uvp, cmp) \
	(((tvp)->tv_sec != (uvp)->tv_sec) ? \
	((tvp)->tv_sec cmp (uvp)->tv_sec) : \
	((tvp)->tv_usec cmp (uvp)->tv_usec))
#define timerclear(tvp)	 (tvp)->tv_sec = (tvp)->tv_usec = 0
#endif /* _TIMEVAL_DEFINED */
 

No gettimeofday(). That's why gcc complained. For solving it, we can define gettimeofday() as a wrapper around GetSystemTimeAsFileTime(), which is the function for retrieving system time in Windows (Windows 2000, XP and Vista). GetSystemTimeAsFileTime() has a resolution of 100 nanoseconds. The complete sys/time.h (and more details) can be found in this excellent page which explains how to build OpenBabel with MinGW. Basically, you have to append the following to the original sys/time.h:

 
/* Provided for compatibility with code that assumes that
   the presence of gettimeofday function implies a definition
   of struct timezone. */
struct timezone
{
  int tz_minuteswest; /* of Greenwich */
  int tz_dsttime;     /* type of dst correction to apply */
};
 
/*
   Implementation as per:
   The Open Group Base Specifications, Issue 6
   IEEE Std 1003.1, 2004 Edition
 
   The timezone pointer arg is ignored.  Errors are ignored.
*/ 
 
#ifdef	__cplusplus
 
void  GetSystemTimeAsFileTime(FILETIME*);
 
inline int gettimeofday(struct timeval* p, void* tz /* IGNORED */)
{
	union {
	    long long ns100; /*time since 1 Jan 1601 in 100ns units */
		FILETIME ft;
	} now;
 
    GetSystemTimeAsFileTime( &(now.ft) );
    p->tv_usec=(long)((now.ns100 / 10LL) % 1000000LL );
    p->tv_sec= (long)((now.ns100-(116444736000000000LL))/10000000LL);
	return 0;
}
 
#else
    /* Must be defined somewhere else */
	int gettimeofday(struct timeval* p, void* tz /* IGNORED */);
#endif
 

Finally, an interesting remark. My friend uses gettimeofday() to initialize srand(). The most common initialization one finds in books and Internet is srand((unsigned)time(0)), but that's a rather poor initialization. Do you want details? Read this excellent explanation by Christian Stigen Larsen: Never use time() to initialize srand().

Thank you for reading!

1. Hi, Jose. Please, could you expand on the reasons why adding people to a late software project makes it later? by José Rodríguez (Venezuela).

That statement is known as Brooks's Law, and it was coined by the renowned computer scientist and software engineer Frederick P. Brooks. Concretely, the original statement found in his 1975 classic The Mythical Man-Month is "adding manpower to a late software project makes it later". Basically, the idea is that adding more analysts, designers or programmers to a project running behind the original schedule will delay it even more.

Broadly speaking, the rationale of Brooks's law is related to knowledge management. First, when new personnel is added to the project, some resources have to be diverted into training or informing the newcomers about the project's status, vision and philosophy. That will delay the project. Further, when the number of people participating in a project increases, so does the number of communication paths. Thereby, more resources (including time) are required in order to distribute the information. Regarding this point, you may be interested in reading my entry on "Knowledge Sharing" in Software Design, Trials and Errors.

2. What is a Reentrant Routine? by Ricardo Orozco (Venezuela)

A routine or procedure P is reentrant (or pure code) if it can be "re-entered" after it is already in execution. Basically, it means that P can be executed two or more times simultaneously, or alternatively, that P can be safely executed concurrently. There are some conditions P must follow in order to be reentrant, and you may check them in the Wikipedia entry for reentrant functions.

Some programs necessarily have to be reentrant. For instance, device drivers. A device driver has to be reentrant because another interrupt may be raised while the driver is running. This means that reentrancy allows for code sharing. For example, if a program consists of 600 KB of code and 200 KB of data, and n users are simultaneously using the program, we would require n x 600 KB of physical memory for the code if the program is not reentrant. But if the code is reentrant we can share it among the n users, saving a lot of memory.

3. How to characterize nasal consonants acoustically? by Rajeev Ranjan (India)
   

A good answer to this question would require plenty of explanations. I suggest you to check on pages 487-514 of Acoustic Phonetics by Professor Kenneth Stevens. But I'll provide you with some hints, anyway.

Nasal consonants are sonorant phonemes, but they exhibit significant losses due to the nasal tract coupling. Further, nasal spectra is relatively very stable during the oral tract closure (there are minimum acoustic alterations). Typically, F1 is located near to 250 Hz, F2 is weak, and F3 is near to 2 kHz. Remember that for these phonemes the acoustic energy also transits the nasal cavities. Such nasal cavities have different frequency properties. But the oral tract, albeit closed, also alters the acoustic transfer function. This transfer function, for simple phonemes such as vowels, includes only poles. However, when the oral tract is closed, the acoustic transfer function also includes zeros. And that changes the output in a great deal. The location of the first spectral zero of nasal consonants depends on the point of oral closure (for instance, the point of closure for /m/ is more anterior than /n/'s).

Thank you very much for your questions, and for reading. I encourage you to send more questions to my email account. So long.

Continuous and Digital Signal Processing

A signal is a measurement of a process, an observation of the behavior of some system. Numerically, a signal is a time-varying or spatial-varying quantity (in the following, for simplicity, we'll assume that the independent variable is time t). Some physical signals, such as speech and image are continuous in time. For instance, the speech signal is a continuously varying acoustic pressure wave. Sometimes, continuous signals x(t) are referred to as continuous or analog waveforms (continuous and analog are typically interchangeable terms albeit analog is a kind of absolute term, and we will not be using it in the following). Continuous signals vary at an uncountable infinite number of times. On its side, digital processing units can only handle sequences of numbers, i.e., they are discrete devices. In order to harness the benefits of digital processing units, continuous signals have to be first discretized (sampled). After sampling, we get a digital signal, which we might use as a representation of the original continuous signal. This sampling process is performed by a Continuous-to-Discrete (C/D) converter.

Summarizing, sampling is the process by which a digital representation of a continuous time signal is obtained. Basically, during sampling we select a finite number of data points (in a finite time interval) to represent the infinite amount of data that the continuous signal contains (within the same interval). If sampling is periodic, we sample x(t) at uniformly spaced time instants. Sampling is by no means a trivial issue, and we have to be careful in selecting the discrete data values... how well does this discrete sequence represent the continuous signal? (We'll study this question in an upcoming post).

This is other important theoretical subtlety of sampling. The C/D sampler that produces the discrete signal is (theoretically) able to handle infinite amplitude precision. Thereby, although the digital signal x[n] is discrete in time, it is continuous in amplitude. This type of signal is called discrete-time signal. Nevertheless, this C/D is an ideal device. In practice, we recur to an Analog-To-Digital (A/D) converter which quantizes each amplitude to a finite set of values closest to the actual continuous signal amplitude. This is the digital signal, which has both the independent time variable and its amplitude quantized. In practice, we work mostly with digital signals.

The Continuous Sinewave

One of the most simple yet useful signal is the sinewave, which is a member of the family of functions expressed as:

A is the amplitude, and we can discard it for the time being. Needless to say, theses are periodic functions whose frequency is given by (in Hz). For instance, if , our sinewave would complete two oscillations in 1 second. The duration of an oscillation (the period) is the reciprocal of its frequency, .

Now, in order to derive a digital representation of such sinewave, we will take regularly spaced samples. The time elapsed between samples is given by the parameter (the sampling period) whose reciprocal, , is the sampling frequency . Then, our discrete signal is:

x[n] is just a sequence of numbers. The first number of such sequence is x[0], the second is x[1], and so further. Therefore, n takes on only integer values 0, 1, 2, ... Notice that similarly to , is also an angle expressed in radians. In an upcoming post, we'll be revisiting how the selection of determines the quality of our sampling.

Essentially, the article Software Design and the Monkey's Brain deals with two intertwined observations:

1. Software Design is a sophisticated trial and error (iterative) activity.
2. Such iterative process mostly occurs inside the mind (at the speed of thought).

In the following, I'll present my own appreciations on this topic. Regarding the first observation, I think that trial and error (I've also found the expression trial by error) is the underlying problem-solving approach of every software engineering methodology, like it or not. Alas, there is no algorithmic, perfectly formalized framework for creating software. In his classic book Object-Oriented Analysis and Design, Grady Booch says:

The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exists.

I totally agree. Nevertheless, some people dislike this reality. Referring to Software Engineering, a few (theorist) teachers of mine rejected calling it "Engineering". These people cannot live without "magic". Indeed, there are significant conceptual differences between software practitioners and some (stubborn) computer scientists, with regards to Software Engineering's nature. These scientists are not very fond of the trial and error approach. In his article, Professor Glass presents some past investigations which verified that designing software was a trial and error iterative process. He also reflects on the differences in professional perceptions:

This may not have been a terribly acceptable discovery to computer scientists who presumably had hoped for a more algorithmic or prescriptive approach to design, but to software designers in the trenches of practice, it rang a clear and credible bell.

I like to think of software construction as a synthesis process. Specifically, there are two general factors in tension: human factors and artificial factors. The former, mostly informal, the latter, mostly formal. From the conflict, software emerges. Let's remember that the synthesis solves the conflict between the parts by reconciling their commonalities, in order to form something new. It's the task of the software designer to conciliate the best of both worlds. Software designers have to evaluate different trade-offs between human and artificial factors.

As a problem-solving activity, software construction is solution-oriented: the ultimate goal of software is to provide a solution to some specific problem. Such solution is evaluated by means of a model of the solution domain. But before arriving to such solution domain model, we have to form the problem domain model. The problem domain model captures the aspects of reality that are relevant to the problem. Later, designers look for a solution, as told, by trial and error. Additionally, the resources available to the designer, including knowledge, are limited. More often than not, empiricism and experience lead the search for a solution. This has an important consequence: software construction is a non-optimal process; we rarely arrive to the best solution (and which is the best solution?).

On its side, knowledge acquisition is other interesting process. During the entire cycle of development, designers have access to an incomplete knowledge. Gradually, designers learn those concepts pertinent to the problem domain model. And, when we are building the problem domain model, it often occurs that the client perspective of the problem changes, and we have to adjust to the new requirements. Interestingly enough, knowledge acquisition is a nonlinear process. Sometimes, a new piece of information may invalidate all our designs, and we must be prepared to start over.

According to Professor Glass' article, the software design activity comprises the following stages (bold text in the below list is literally taken from Professor Glass' article):

1. Develop a complete understanding of the problem to be solved. It comprises formulation and analysis of the problem, which in fact, should complete the problem domain model.
2. Build a mental model of a proposed solution to the problem. It corresponds to a search for the solution. Thereby, the final product should be the solution domain model.
3. Mentally execute the model on a sample input to see if it does indeed solve the problem. Clearly, we are validating our solution domain model.
4. If the output of the execution is incorrect (as will often be the case in the early stages of design), expand the model to correct the deficiencies, then execute again. We detected an error in the trial, therefore, we will alter our model in order to conform to the problem specifications.
5. Once the output of the execution of the model is correct, choose a different sample input and repeat the process. Keep validating the solution domain model.
6. Eventually, the expectation is that a strongly enhanced mental model will be able to solve all of the sample inputs considered. Thereafter, we can specify the solution.
   

Software Design Considerations

During all these trial and error iterations, software designers have to keep plenty of factors in their minds in order to solve the tension between human and artificial factors. Software design offers plenty of opportunities, mostly opportunities for being wrong. The following are some of such factors that may force us to readjust our hypothesis in the light of new facts:

• Heterogeneity - Software runs over heterogeneous resources. Software design must take into account the variety and difference in hardware, networks and other support software systems. Some of those "external" systems may be very mutable on specifications and implementations.
• Design Envelope - A design envelope is the framework on which the solution is defined. Essentially, this framework comprises all the design decisions and trade-offs. As such, the framework also establishes the bounds for the solution. A good design should try its best in order to anticipate change. Nevertheless, foreseeing any possible modification to the system's specification is totally impossible. For instance, plenty of specification's errors can only be discovered when users start working with the system. There may be several other causes for modifications, such as technology changes, market's dynamics, performance or usability problems, implementation constraints, and so further. Sometimes, we are lucky enough and we can introduce changes to our design, with relatively few problems, within the current design envelope. However, more often than not, modifying an existing design can be quite an arduous task, which might require a significant or total redefinition of our design framework. A clearer explanation of the notion of Design Envelope can be found in Facts 19 and 44 of Facts and Fallacies of Software Engineering, also by Professor Glass.
• Information Hiding - Building software implies describing a system at different levels of abstraction. By using abstraction, we hide any unnecessary internal details. Regarding such information hiding, David L. Parnas, in his classic paper "On the Criteria to Be Used in Decomposing Systems into Modules", suggests that modularity, understood as an assignment of functional responsibilities to system's modules or components, helps software design to keep a bigger flexibility and comprehensibility, and promotes a lowering of costs. Each system's module should hide some design decision.  Nevertheless, information hiding introduces an interesting paradox, which also involves the design envelope. When designing, we proceed to decompose the system into modules, assigning each some responsibility. For handling complexity, we would like small software pieces, and ideally, modifying any of such pieces should have a minimum impact in other parts of the system. That is, we strive to arrive to a clean design framework. But, at the same time, such well-structured framework will likely turn into an obstacle to accept future changes!
• Security - Primarily, a software system manages and is comprised of information. Such information may have a high value to the software's users. Therefore, software design must consider the security risks. I recall that security in software systems has three parts: integrity (preventing data corruption), confidentiality (preventing access to unauthorized users) and availability (preventing that access to the system may be maliciously interfered). However, it's impossible to think in advance of all possible hostile acts against the system.
• Failure handling - Good software design always consider potential scenarios of failure. That's easier said than done. Frequently, even detecting the failure may be a hard task. That's other reason why design should always favor software construction based on low-coupled components: theoretically, it should be easier to isolate and identify the part at fault. Now, if a failure occurs, what will the system do? Mask the failure? Inform the user about the failure and ask her for directions? Try to automatically recover from failure? Nice questions, even prettier core dumps.
• Usability - Pretty systems are prettier. However, "pretty" depends on subjective appreciation, and ultimately, on the target market's characteristics. Personally, I think that the most usable systems are those that just behave like expected. Albeit a simple observation, it means a lot for designers. For instance, usability means that system's resources should be accessed using consistent operations and procedures. Here's an informal metric that I love to use to assess our design quality: when, during the software cycle, we have to expand our design to comprise new functionality, and suddenly the consistency of our operations is lost, we can be sure that something is very wrong.
• Reusability - Clean, modular software design almost automatically leads to software reuse. And software reuse offers plenty of benefits: quality improvements, cost and effort reductions, and a very important (yet sometimes neglected) opportunity: rapid prototyping. Building on reusable components, we can quickly develop some prototypes, and receive early feedback from our clients. Further, prototypes may help to uncover previously unnoticed requirements.
• Knowledge Sharing - Software is a multicolor creature. Besides being a product, a good software design is also an invaluable learning tool for new and future designers. Good software design is immortal. We should be fully aware of such fact. Further, knowledge sharing also considers communication among project's members. Typically, designing software systems requires dealing with a lot of complexity, too much information to be handled by any one person. Development requires collaboration of people from different technical backgrounds and knowledge domains. Therefore, a proper handling of communication paths is vital for the success of the project. Yet, we should proceed carefully, as there is other confirmed observation regarding communication: albeit staff size always affects development time, it must be realized that, the more the staff, the more resources will have to be assigned to handle the communication paths in order to distribute the information. And remember that an uncontrolled communication path is also an opportunity for problematic misunderstandings.
• Maintainability - Software is rarely immutable. Sooner or later it has to be modified for correcting errors, adapting to new hardware or software interfaces, improving performance, or extending its functionality. A good design should allow for lower maintenance costs.
• Marketability - I'd love not to think about markets. Nevertheless, markets are the typical reason why software is built. Even the design of non-profit software is ultimately influenced by the market's trends. Therefore, most of design decisions should always be studied in the light of market's nature and expected behavior.

What about the monkey?

In Software Design and the Monkey's Brain, the "Monkey" refers to a January (2008) news about a group of scientists in the U.S. and Japan which have successfully used a monkey's brain activity to control a robot, transmitting the signals over the Internet. You can read the full news here. The most interesting achievement of that research is twofold: first, there is the ability to separate mental activity from its natural actuators, and then we have the possibility of transmitting the mental signals (of the monkey) to remote robotic articulations. In a future, this kind of research is expected to arrive to beautiful results: it could be possible to restore mobility to paralyzed people, by enabling them to use their thoughts to control auxiliary movement structures (artificial exoskeletons).

It's obvious that thoughts are what propels every human activity, naturally including software design. Thinking allows us to model the reality of the problem and that of the solution. However, the iterative trial and error process required for creating software occurs inside the mind, at the speed of human thought. And the mind is much faster than any "external" tools and procedures we may use for software design. And that's a BIG problem for software design: first we have to "extract" all the ideas, rationale and models from our heads, and thereafter translate them to several common visual and written languages. That takes a lot of time and effort.

What if we had a device like the one used with the monkey? The device would recover our brain signals, converting them automatically into models and code. Wonderful. Rationale management (registering all our design assumptions and context) would be also magically recorded. This scheme would indeed be very helpful, and will likely await for us in the long (?) road. Nevertheless, I see an interesting problem: Peopleware. Most systems are too complex to be understood by just one designer. Communication is mandatory. How would we coordinate all those mental signals? Such signals would travel from mind to mind? I think that sending a signal from the mind to an exoskeleton is a very different thing to sending the signal from mind to mind.

But it will be quite interesting to know how Software Engineering will adapt to the new "mental" schemes.

Author Take a look at my profile here.

Meta

2008 - August, 8th

I removed the entries for Scalability and Soft Skin, and replaced them with the proper terms Design Envelope and Information Hiding, respectively. I'd like to thank Professor Robert Glass and the commenters for some specific suggestions and corrections. All remaining errors are, of course, my sole responsibility.

In first instance, I think that the answer is that you can't. IIRC, Childers' toolbox allowed for inversion of the sentence "we were away a year ago". But that's a very convenient sentence to invert, because most of its relevant acoustic information can be clearly seen with a formants analysis. Nevertheless, that's not the case for fricatives (and nasals, for instance, have other interesting problems too).

For my thesis, I developed my own inversion toolbox. But no matter the toolbox, you require a "source" of information for inversion. That information may be spectral energy distribution, formants, etc. For fricatives, formants are out-of-question. Fricatives' spectrum differs importantly from voiced phonemes', as you know. When we utter fricatives, the oral tract naturally adopts a specific "constriction" configuration... and such configuration would yield a formantic structure. The problem is that turbulence generated in the oral tract hides resonances, and that's why formant tracking is misleading in such cases.

My approach then was to use other type of information. I analyzed the spectrum of fricatives, locating those frequencies with the higher concentration of energy. During inversion, I favored articulatory configurations which would yield a higher concentration of energy in those detected "zones" of energy. Acoustic energy follows some relatively evident patterns. For example, /f/ exhibits a relatively uniform distribution of energy, whereas /s/ reveals an energy peak about 5kHz.

You could improve inversion further by harnessing a simple observation. Remember that short acoustic tubes have resonances in higher frequencies. You could tell your articulatory model to adopt configurations yielding short frontal acoustic tubes (which should lead the model to adopt an "anterior constriction" configuration). The only problem this approach has is that you're providing the inversion method with some "extra" information. It depends on the goals of your research. If you don't have to invert by using information coming from the analysis of "real" utterances (which is rarely the case, though) you may directly instruct your inversion algorithm to invert directly a frequency of 5kHz for the /s/ and of 18 kHz for the /f/... that is a cheap inversion, but would confirm your model's relative suitability for inverting such fricative phonemes.

I'll expand on this in upcoming posts.

Books

• Gunnar Fant - Acoustic Theory of Speech Production
• James L. Flanagan - Speech Analysis, Synthesis and Perception
• Kenneth N. Stevens - Acoustic Phonetics
• Paul Boersma - Functional Phonology
• J. M. Pickett - The Acoustics of Speech Communication
• D. G. Childers - Speech Processing and Synthesis Toolboxes
• A. Seikel, D. King and D. Drumright - Anatomy and Physiology for Speech, Language and Hearing. Lovely book.

Papers, Theses and Slides

• P. Mermelstein - Articulatory Model for the Study of Speech Production. Mermelstein's paper is a classic, and a mandatory read for anyone interested in the subject of articulatory synthesis and inversion. It describes the most used articulatory model to date. Albeit 3D articulatory models are the current trend, Mermelstein's model is still very useful for research. This version has some low-quality pages. I'll provide a better scanned version later.
• Michael Portnoff - A Quasi-one-dimensional Digital Simulation for the Time-varying Vocal Tract
• J. Dang and K. Honda - Construction and Control of a Physiological Articulatory Model
• I. Howard and M. Huckvale - Learning to control an articulatory synthesizer by imitating real speech
• Olov Engwall - Vocal tract modeling in 3D
• R. Sproat, M. Ostendorf and A. Hunt (Editors) - The Need for Increased Speech Synthesis Research
• W. Hess - Artikulatorische und akustische Phonetik (German) This concrete presentation of articulatory and acoustic phonetics by professor Wolfgang Hess is one of the best in the web.
• Qiguang Lin - Speech Production Theory and Articulatory Speech Synthesis.

A few of my own documents

My research is just a drop compared to the above oceans. Although some of the ideas and assumptions I followed are already old, someone may find them useful:

• J. Brito - Genetic Learning of Vocal Tract Area Functions for Articulatory Synthesis of Spanish Vowels.
• J. Brito and W. Rodríguez - Multipopulation genetic learning of midsagittal articulatory models for speech synthesis.
• J. Brito - Técnicas de Aprendizaje Artificial Aplicadas al Problem Inverso de la Síntesis Articulatoria de Voz por Computadora (Spanish) My doctoral dissertation. I'll upload it later... I don't remember where it is

Finally, please notice that the list is by no means complete or comprehensive. Some very important papers are missing, such as Flanagan and Ishizaka vocal fold modeling, Maeda's simulation of the vocal tract, Rubin's description of a synthesizer, Sorokin's model and others. I'll be adding more items in the future.

Cygwin

Cygwin allows to run a collection of Unix tools on Windows, including the GNU development toolchain. However, at its core, cygwin is a library which translates the POSIX system call API into the pertinent Win32 system calls (system calls are often abbreviated as syscalls). Therefore, cygwin is a software layer between applications using POSIX system calls and the Win32 operating systems, which allows porting some Unix applications to Windows. This way you can, for instance, have the Apache daemon working as a Windows service. Other very attractive feature of Cygwin is its interactive environment: you can run your shell quite nicely, and run your Autoconf scripts, for example. However, porting means recompiling. There is no binary compatibility, and your program cannot run in computers without Cygwin (without CYGWIN1.DLL, more precisely). Furthermore, albeit some progress has been made, Cygwin is relatively slow (it's a POSIX compatibility layer, after all.) If possible, I prefer to recompile my applications directly with MinGW. For me, this allows for a faster development cycle. Note, though, that Cygwin can compile MinGW-compatible executables. It's just that, as aforesaid, I prefer to work with MinGW directly. I only work on Windows if I have to develop applications for Windows. But Linux's development tools are the best, and we can access several of them by using MinGW. I think that Cygwin is best suited for general cross-development and for handling complicated software porting.

System Calls and int 0x80

A system call is a request by an active process for a service performed by the operating system kernel. Remember that a process is an executing (running) instance of a program, and the active process is the process currently using the CPU. The active process may perform a system call to request creation of other process, for instance. Or perhaps the process needs to communicate with a peripheral device. In Linux on x86, int 0x80 is the assembly language instruction that is used to invoke system calls. int 0x80 is a software interrupt, as it will be raised by a software process, not by hardware devices. Before invoking such interruption, our program have to store the system call number (which allows the operating system to know what service your program is specifically requesting ) in the proper register of the CPU. Every interrupt is a signal to the operating system, notifying it about the occurrence of an event that must be computationally handled.

Application Binary Interface

Generally speaking, an Application Binary Interface (ABI) is the interface between an application program and the operating system. Conceptually, it's related to the more well-known API concept. But ABIs are a low-level notion, while APIs are more leaned toward the application source code level. If your program uses an specific API, you will be able to compile it on any system which implements that API. Similarly, a program (or more generally, a compiled object code) which uses a specific ABI will run (without the need for recompilation) on any system offering that ABI. Specification of ABIs includes, but is not limited to, details such as:

1. How applications make system calls to the operating system.

2. System call numbers.

3. Calling conventions (how parameters are passed to functions, and how their return values are received).

4. The format of the object code (COFF/PE, ELF, etc.)

To consolidate ideas, notice that a relatively backward-compatible ABI is which has allowed several older applications to run on newer versions of Windows.

Now a few things should be quite clear. First, Cygwin is a software layer at the API level. Second, interrupts are a concept from the ABI level. And it's obvious that Linux syscalls are entirely different from Windows syscalls. Further, in Cygwin you don't make raw system calls... it's CYGWIN1.DLL which does the needed Windows system calls according to your program requirements. The ABI of software compiled with Cygwin is that of Windows systems. You cannot use a Linux ABI's thing, such as int 0x80, and expect that your program runs fine on Windows.

If you're programming in assembly, 0x80 only works in Linux. For DOS/Windows, you must use 0x21, 0x25, 0x26, etc. That's the rationale behind my decision for using a function of the C library, printf, in order to avoid this problem in the example code of this post.

The Truth Reflected in the Mirror

You cannot use a Linux ABI's thing, such as int 0x80, and expect that your program runs fine on Windows. That's not entirely true. Under Windows, you can install a vectored exception handler which traps the interruption request, and with some coding translate the trapped information into the Windows equivalent. But that amounts to writing an Linux kernel emulator.

If you are in a hurry, perhaps you'll prefer the wise path of virtualization. By using a virtualization engine like VMWare and Xen you can install and execute a guest operating system on a host system. Such virtual machines offer a full resources abstraction which allows you to use the guest operating system almost at its full. For some tasks, the coLinux's approach may be preferable. Cooperative Linux (coLinux) allows the Windows and Linux kernel to run simultaneously on the same machine, but unlike traditional virtual machines, coLinux shares resources that already exist in the host.

coLinux is a very elegant and exciting project. However, installing and configuring coLinux may be a hard task. After installing your Linux distro, it's not easy to configure the window manager, the networking facilities, and other things. The best resource I've found in the net for such chores is this post by Sofeng: Install coLinux (and Ubuntu Hardy) on Win XP using Slirp to internet and TAP to host behind a corporate firewall/proxy server. It's a very recommended reading.

Nevertheless, I have a couple of quick tips for those who want to start programming in assembly as soon as possible. Please, notice that software is constantly evolving and the following tips may be obsolete for the time you're reading them. Review the excellent coLinux documentation beforehand. During coLinux setup, select the Ubuntu distribution. After installation, go to the folder where you installed it, and decompress the file Ubuntu-7.10.ext3.2GB.7z. Also put UbuntuSlirp.bat and coLinux.conf into your colinux directory (these files may require some tweaking according to your system.) Run coLinux by executing UbuntuSlirp.bat. Linux should boot nicely. Use root as login and password. And that's it. You'll have Linux on Windows. But developers need the GNU development tools. Install them by executing apt-get install gcc

At this point, you should have the GNU assembler (as) installed. Now you can type your programs, and assemble/run them. And you can use 0x80 in your assembly program! For example, I typed the hello, world program of the tutorial by Miyagi, and it assembled and ran just fine.

As always, your feedback is welcome.