Several optimizers are available:

• Nelder-Mead or simplex minimization
• Unconstrained gradient-based minimization

The usual criterias can be used:

• Iteration limit
• Parameter change (relative and absolute)
• Cost function changer (relative and absolute)
• Composite criterion generation (AND/OR)

Different direction searches are available:

• Gradient
• Several conjugate-gradient (Fletcher-Reeves, …)
• Decorators for selecting part of the gradient
• Marquardt step

Finally several line searches (1D minimization) were coded:

• Fibonacci and gold number methods (exact line searches)
• Wolfe-Powell soft and strong rules
• Goldstein line search
• Cubic interpolation

Additional helper classes can be used:

• Finite difference differentation (central and forward)
• Quadratic cost (for least square estimation)
• Levenberg-Marquardt approximation for least square estimation

Although it is the 0.1 version, the code is quite stable and is used in the learn scikit.

The package can be easy-installed or can be found on PyPI.

Several tutorials are available or will be available on the future at the following locations:

• http://matt.eifelle.com/tag/optimization/
• http://projects.scipy.org/scikits/wiki/Optimization/tutorial

Content and opinions

The audience of this book is mainly people that do not know much about software but that want to know about a story that drove people for several years. There are a lot of fkashbacks inside software history or parenthesises on software.

Also the book is acclaimed by the critics, I didn’t find it that much interesting. It is very difficult to read the whole book, as the the thread goes from history to context to side stories to the main stories, sometimes after each parenthesis. This is tiresome, and is a drawback for a good book when you want to relax a little bit. Here, you won’t be able to do so, you’ll have to keep focusing on what the author wants to tell you (and that’s not really easy).

Conclusion

Not as much fun as I expected, but still, there are some passages that may be worth it for managers that don’t want to read a book on software project management. I won’t recommend it, but you may still want to learn from other people’s mistakes.

Dreaming in Code: Two Dozen Programmers, Three Years, 4, 732 Bugs, and One Quest for Transcendent Software
Price: $11.92

Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software (Paperback)
by Scott Rosenberg
ISBN: 1400082471

Price: USD 9.86
53 used & new available from USD 5.06

| 4 | 70

Content and opinions

The first part is dedicated to the reasons why a software project can fail. It starts with 12 reasons of why software is different than other fields. This implies some assumptions that can differ from the usual project management. The last chapter is a simulation of what a failing software project is. All in all, the main message passes, but I think it is too harsh. The underlying idea is that software is different than all the other fields, but in fact, it may be all the same (at least on the points that were underlined): building a bridge is something we know how to do through usual management, but it can still run late/too expensive/… Besides, the example is overdone. It cumulates all the typical mistakes that we know now how to avoid.

The second part gives the pieces of advice to fix what the first part uncovered. Three agile processes are explained, then tools to budget with one of these processes. the last is the example of the first part reloaded with agile methods. I agree that agile methods are an answer to the software management project, but each time software management is really opposed to usual management. There are issues that are still really different in software projects: defining the needs of the users. When you build a bridge or when you build a house, you know what you want. You know the number of ways, or the number of doors/windows/rooms, … In software projects, you don’t know how many doors you need. Another issue is that people think that software is easy to do, so it’s easy to add something else (mainly because it is mandatory… or not).

Conclusion

If the book is really easy to read, there are some shortcuts that did bother me: the two examples are caricatures of reality (not even a real example where things went well or really bad, they are a story), and software management is also exagerated compared to project management. Perhaps the real conclusion is this one: exageration. Software project management is too difficult to be explained by a caricature: it may lead to the opposite effect.

Software Project Secrets: Why Software Projects Fail
Price: $49.49

Software Project Secrets: Why Software Projects Fail (Expert’s Voice) (Hardcover)
by George Stepanek
ISBN: 1590595505

Price: USD 21.26
44 used & new available from USD 1.97

| 4.5 | 6

Today’s accelerators are not there yet. The tools are not ready yet (code translators) and usual programming practices may not be adequate. All the ecosystem will evolve, accelerators will change (GPUs are the main trend, but they will be different in a few years), so what you will do today needs to be shaped with these changes in mind. How is it possible to do so? Is it even possible?

Available code translators

Code translators are the easiest path to solution. I know two of them.

The first is the PGI compiler. It only supports CUDA and the Fortran and C99 language. I didn’t use it yet, also I plan of testing it in the near future. It is based on pragmas, and the compiler generates the CUDA microcode.

The second solution is HMPP. It supports more than just CUDA (also CAL/IL or OpenCL) and Fortran/C (also Java now). As the PGI compiler, it is based on pragmas, and a excellent thing is that it detects the available accelerators and launches the correct kernel (if you authorized it) or the original code. You can also modify the generated code to put your own (you can tune the code for instance, which may give you an additional x2 factor). Unfortunately, it is not possible to call functions inside the parallelized kernels, which means that only simple or badly-written (too many lines or duplicated code) kernels can be called. I think this is the same for the PGI compiler.

It seems that code translators still need work:

• only few accelerators are supported (CUDA, and sometimes CAL/IL or OpenCL),
• almost no langage (Fortran/C/Java, a lot of Virtual Machines should be able to use them natively, without developers using specific tools),
• only one function can be parallelized at a time.

The last point is currently the biggest issue. You need to cut your function int pieces to have clean code and a good portability/evolutivity for the future.

This is why one still need to program a lot for those accelerators, and so we need to adapt our programming practices, develop in the accelerators’ native langages (even if we know that they may disappear in a few years).

Developping your own “tool chain” for accelerators

For accelerators, there are a lot of things that needs to be done each time: copying some data, computing and getting some data back. These are the steps that code translators automate, in fact it is a common practice to use tools to automate stuff. The issue is that complex kernels are not supported by those translators. So what?

Creating automatic functions that will copy the data you need is in fact very common in metaprogramming. Coding the kernel on an accelerator is in fact not that difficult: the manufacturers provide the needed compilers (that’s what nVidia does and the success of the tool chain cannot be denied), and this is really the cornerstone. One has to write more code, some parts are less portable (because they are written in one of the accelerator’s languages), but in the end, with metaprogramming, the code can be better tuned, enhanced and read. This is the leverage of the accelerators.

Conclusion

Why do we care developing for accelerators? We know that they will go away. Before they do, they are the only way of speeding up our software. Code translators are the best tools to develop in a portable way, but they need time to support more accelerators, languages and method of programming. When CPUs will be on a par with accelerators, their progress will help compilers to target them correctly. It’s just a matter of time.
Meanwhile, metaprogrammin is the next best solution to automate processes that code translators cannot support yet.

Content and opinions

The book consists of a lot of pieces of advice (the brand of Pragmatic Bookshelf, the publisher), not too many so as not to be bored at the end.

It starts with the field (i.e. language and technology) you may focus on. Either you want to be at the edge, or rely on a mature technology. It depends, but there are some specifics you should know if you want to bloom.
The second aspect/part is dedicated to your network: how do you get information and how do you give it? Who should you be working with? All these aspects help you be the best at what you do.
When you actually work, there are some advice to make you really essential to your company: speak your mind, read the leader’s one, make your job profitabe to your company, …
The fourth part is about marketing. It is perhaps surprising, but you have to sell yourself. You may be the best in your field, have an excellent network and are essential to your company, if it doesn’t know it, you’re screwed. Sell yourself, this will be also great if you want/have to switch jobs.
Your carrier path is not clear with all the technology changes, with the current economical situation. You have to ready yourself to this, which is what the last part is all about: prospects and your future.

Each time the chapter is clear and goes straight to the point. The content is also explained with music metaphors, as the author is also a musician. Other well-known people give their opinion on some chapters of the book, each time shedding a new light on our own situation.

Conclusion

Pragmatic advice starts with obvious advice. If the content seems rather obvious (especially if you want to be better at your job, you may have applied a lot of the pieces of advice of the book), it’s always good to have it reminded, as we tend to not see the forest of the trees.

The main idea is to be at the edge. Learn from others, listen to the trends and the people who make them, and act accordingly.

The Passionate Programmer: Creating a Remarkable Career in Software Development
Price: $20.47

The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life) (Paperback)
by Chad Fowler
ISBN: 1934356344

Price: USD 16.29
41 used & new available from USD 14.60

| 4.5 | 28

A function to optimize

The function I’ll be trying to optimize is the following one:

class Function(object):
  def __call__(self, x):
    t = numpy.sqrt((x[0]*x[0]+x[1]*x[1]))
    return -numpy.sinc(numpy.pi * t)

This function is a 2D sinc function for which I try to find the maximum, which is in (0,0). To do so, I’ll be minimizing the opposite function.

2D display of the sinc() function

3D display of the sinc() function

The simplex method

The simplex method, or polytope or Nelder Mead method, uses a simplex/polytope in the parameters space to search for the global minimum of a function.

The set of current points is sorted, and a mean parameter point is computed with the n best points. The symmetric point of the worst/unsued point with respect to the mean point is compared to the current set, and depending on the result, additional steps of expansion or contraction are taken.

At the end, unless the symmetric point, the expanded or the contracted points do not enhance the solution, the mean cost of the simplex points is always enhanced.

The polytope optimizer usage

The framework is based on several principles I’ll will talk about later. I will only explain what I will be doing.

Once the function is defined, I’m set to optimize it:

  from scikits.optimization.optimizer import PolytopeOptimizer
  from scikits.optimization import criterion
 
  from function import Function
 
  import numpy
 
  optimizer = PolytopeOptimizer(function = Function(),
                                x0 = numpy.random.randn(3, 2) * .5,
                                criterion = criterion.OrComposition(criterion.RelativeParametersCriterion(0.00001), criterion.IterationCriterion(20)))
  optimizer.optimize()
  print numpy.mean(optimizer.state['new_parameters'], axis=0)

The creation of the optimizer is done by calling PolytopeOptimizer with several arguments:

• function which is the instance of the function to optimize
• x0 is the array of starting points (n+1 points of n-dimension points)
• criterion is the stopping criterion, a complex criterion indicating to stop when some iterations are done or if the set of optimal points does not change much

Then, I can call the actual optimization, and display the mean of the set of optimal points.

To end this post, here is a video of the evolution of the optimization.

All the code is available freely on the scikits SVN and the tutorials repository on Launchpad.

Content and opinions

The book is split in two parts: what Google does and what it may be doing in several different industries.

The laws of Google are what steers Google (or at least it what is steered them at some point). Focusing on client needs, decentralizing your industry, this is basically the core of Google. The book describes the implications of this on the client behavior, and on how information flows on the Web: the Dell experience is blatant is that matter. In this part, Jeff Jarvis says that almost everyone can use this approach, but I’m not so sure. Jeff uses the Google approach to money, saying that you can earn enough money through moneytizing your website through advertisement. With the current crisis, I don’t know how this pattern can be applied to everyone. At some point, you will still need a lot of classic webstores for web journals/magazines. The current discussion between News Corp, Google and Microsoft is clear about that: even with the visitors Google provides, News Corp does not make enough money. Well, it also be that News Corp is not embracing change as it should be. I still think that not everyone/every industry (that sells content) can make a living with just moneytizing.

Still, the ideas are very clever and a lot of things can be used for anyone (like giving power to the clients to help you create a better product, warranty service, …)

The second part tackles several industries that may benefit from the Google way. The first and obvious ones are the movies and music ones. Needless to say that their path is currently exactly this opposite, and for the music industry this means far less customers. In France we have the same issues, with these industries trying to keep their customers the wrong way. They alienate us, and this means that we run from them. Indeed, a Google approach is better suited. Although I don’t agree with Jeff Jarvis on the Intellectual Property (the authors must make a living, I’m not talking about the majors and the labels that can make money in different ways), a half-way between the current status and its proposal may lead to a far better place to watch movies and to listen to enjoyable music (it’s not the case at the moment at all).

Books are also an industry that may change, but they are still many pitfalls in the current approach. Jeff Jarvis praises the Amazon model, but for eBooks, I think it is really lame. The price for an eBook is the same as the price for a real book, there are no free updates (this is something an eBook would benefit from, I hate to see one of my books being superseded by a new version) and with DRMs, the market is closed. Jeff Jarvis states that eBooks are great because they can last longer than books. For the moment, thanks to DRMs (and Amazon’s Kindle), I don’t think that an eBook in another format than a pdf can last longer than the life of the Kindle/Nook/… it uses. When the eBook market will be opened, I think the situation will evolve. It’s sad that a firm that is praised by Jeff Jarvis for its Google attitude fails so short in this new market.

There are other chapters for other domains, the one that was the most astonishing is the energy one. The rest is decent IMHO, so I will not speak about them. Google approach to energy is to find a new source of energy (hurrah, but everyone is doing the same). The issue is that Google almost needs an exponential supply, which cannot be. So what does it say? I think the Google way is the right way for the next decade, at least. After that, we will face the end of a Ponzi scheme of some sort with the Google way (moneytizing, network and dillution). Google was the first on this scheme, and it benefits from it. The followers do not earn as much, the next ones even less, … The energy wall might be what will hit Google first: the next energy source is not yet discovered, and to fulfill its need, Google will still have to wait several years, years during which it will use the current supplies (projection says that new energies will account for less than 25% in twenty years IIRC).

Conclusion

Even if I do not share the Google Dream, there are several laws that our old industries have forgotten about. Google has used them extensively, and it is a good thing. We should all do the same, but we also need to step back and have some insight on the Google way. As with every industry, Google has its golden age and it may be now. It will end in some years, and as we listen to this trend now, we will have to stay alert to the new one then.

What Would Google Do? (Hardcover)
Price: $19.43

What Would Google Do? (eBook)
Price: $12.59

What Would Google Do? (Hardcover)
by Jeff Jarvis
ISBN: 0061709719

Price: USD 17.81
58 used & new available from USD 14.25

| 4 | 99

Content and opinions

The book starts with two chapers on what actions to take before parallelizing and what can and what cannot. Before the usual algorithms that can be parallelized, the author takes three chapters to explain how you may achieve your goal. Ensuring correctness is a difficult task, so the book gives 8 rules to help and then an explanation of several support libraries that can be used.

The biggest part of the book, as I’ve hinted, is dedicated to simple but usual algorithms that may be parallelized: sums and scans, mapreduce, sorts, searches, and graph algorithms. Each time, several different algorithms are first coded in a serial way and then parallelized with possibly different support libraries. Also each time, the efficiency, the simplicity, the portability and the scalability conclude the sub art: it helps standing back.

The last chapter is a small overview of the additional tools that you may use (but they are not mandatory). They are mainly Intel’s tools, but it’s mainly because Intel provides the developer with some of the best tools.

Conclusion

Although the author works for Intel, he doesn’t expose Intel tools more than others. The book tone is adequate, not too much serious, not like a “For Dummies”, so just enjoyable.

If you need advices to parallelize your applications and you don’t want to buy Patterns for Parallel Programming, buy this one (well, buy it anyway).

The Art of Concurrency: A Thread Monkey’s Guide to Writing Parallel Applications
Price: $40.49

The Art of Concurrency: A Thread Monkey’s Guide to Writing Parallel Applications (Paperback)
by Clay Breshears
ISBN: 0596521537

Price: USD 40.11
34 used & new available from USD 27.05

| 3.5 | 5

I’ve searched if someone has already used this new version to create a VST plugin. The only blog post I’ve found does not use the Qt Solution and is not perfect. According to the documentation what is missing in this solution is precisely what the Solution should do. So let’s try it.

So I’ve download the 2.4 VST SDK as well as Qt 4.5 and the WinMigrate Solution. As I’ll be using Qt with signals and slots, I used SCons to build my small plugin.

Designing the interface and testing it

The interface is really simple: a label with a name, the value of the gain and a slider. Here is what it looks like in Tracktion 3:

The slider takes values from 0 to 99, value that will be displayed in a label. This will be the gain factor in percentage.

Nothing fancy here with the class header:

class QVstPanel : public QWinWidget
{
  HWND h_parent;
  AudioEffectX *again;
 
  QLabel *valueLabel;
  QSlider *slider;
public:
  QVstPanel(AudioEffectX *again, HWND h_parent = NULL);
};

The panel is created with a link to the actual audio effect (needed in the future) and the parent HWND given by the host.

The actual code is even simplier:

QVstPanel::QVstPanel(AudioEffectX *again, HWND h_parent)
:QWinWidget(h_parent, NULL), again(again), h_parent(h_parent)
{
  setAttribute(Qt::WA_DeleteOnClose);
 
  QLabel *label = new QLabel("Gain", this);
  valueLabel = new QLabel("0", this);
  slider = new QSlider(Qt::Horizontal, this);
  QHBoxLayout *layout = new QHBoxLayout(this);
  layout->addWidget(label);
  layout->addWidget(valueLabel);
  layout->addWidget(slider);
  setLayout(layout);
}

Now this is the class that will be opened by the VST editor this way:

class QtAGain : public AEffEditor
{
  QWinWidget* widget;
  AudioEffectX* effect;
 
public:
  QtAGain(AudioEffectX* effect)
    :widget(NULL), effect(effect)
  {
  }
 
  ~QtAGain()
  {
  }
 
  bool open(void* ptr);
  void close();
};

bool QtAGain::open(void* ptr)
{
  AEffEditor::open (ptr);
  widget = new QVstPanel(effect, static_cast<HWND>(ptr));
  widget->move( 0, 0 );
  widget->adjustSize();
  widget->setMinimumSize(widget->size());
  widget->show();
 
  return true;
}
 
void QtAGain::close()
{
  delete widget;
}

Now, in AGain’s constructor, I can add my custom editor:

  QtAGain* again = new QtAGain(this);
  setEditor(again);

So there isn’t anything really fancy, it kind of works out of the box. Unfortunately, it doesn’t work as well as in T3 in every host. I cannot resize the window VSTHost gives to the open() method, even if I tested it with almost all solutions I’ve found on MSDN.

Adding interactivity

Now, I will eventually use the power of Qt. The QtAGain class will be a QObject, as will be the AGain effect. This way, I can connect signals from the GUI to the effect when a parameter is modified by the user, and vice-versa, the UI will be updated when the effect sees a parameter change (indicated by the host for instance).

So I add a connection inside the QVstPanel constructor to a new slot that will update the underlying effect:

connect(slider, SIGNAL(sliderMoved(int)), this, SLOT(update(int)));
 
void QVstPanel::update(int value)
{
  valueLabel->setText(QString::number(value));
  again->setParameter(0, value / 100.);
}

The trouble arises from the effect: what should I do if the effect gets a setParameter that didn’t come from the UI? If there is no UI, everything is fine though. So I will add a signal inside QtAgain, the editor, that will forward a signal emitted by AGain only if the UI is up.

void AGain::setParameter (VstInt32 index, float value)
{
  fGain = value;
  emit update(value);
}

So now, the signal that the UI will get is a float, so I can reuse the name update() for my slot:

void QVstPanel::update(float value)
{
  int intValue = value * 100;
  valueLabel->setText(QString::number(intValue));
  slider->setValue(intValue);  
}

Of course, you will have several parameters inside your VST plugin, I suggest you use the editor instance to the mapping between the effect and the different slots you may have inside your UI.

Conclusion

Although I couldn’t get it to work with VSTHost (the host widget is not resized), I think the QWinWidget is a good class to help developing Qt VST plugins. I may want to use this skeletton to test some digital effects with a cool UI.

If you have a solution to make VSTHost work, I’m all ears.

The code is available on Launchpad.