Slashdot Mirror

As it turns out many of these scheduling optimization problems are in the NP complete class of problems.

Scheduling is indeed in NP. But, the mathematics behind the scheduling and the interface are currently (generally speaking) both crap. I could do the mathematics -- probably map the problem into CPLEX which, while not free, is indeed considered much faster for nearly all LPs, ILPs, MILPs, etc than the open sourced flavors. Of course, being the good programmer I like to think I am, I'd write the set of functions that call CPLEX's APIs so that they could easily be swapped out for some other ILP solver.

Nevertheless, I've seen the front end of two different expensive commercially available course schedulers. They were crap, and there's no excuse for a crappy front end, because, contrary to popular belief, HCI is not NP.

While still not on par with Tufte's graphic quality, there are quite a few packages that attempt to produce new displays with high information density for a variety of contexts. See for instance Discovery and some other tools of the same kind: KDNuggets

The field of Ops Research (OR) started in WWII to find shipping routes that minimized encounters with U-boats. While it is typically considered a more applied field, it relies heavily on theoretical mathematics for its basis and many of the good OR companies employ a lot of theoretical math phd's. some companies to check out:
SPA: http://www.spa.com/
ILOG: http://www.ilog.com/
Metron: http://www.metsci.com/
DA: http://www.decisive-analytics.com/
MITRE: http://www.mitre.org/
LMI: http://www.lmi.org/

There are plenty of others. these are just a few off the top of my head.

If you have a complex enough set of rules, it might be better to pony up the licensing costs for Ilog. It's native .NET code, and very capable.

This is the application area of "operations research". The OR society is doing a marketing campaign . There are a lot of packages for this type of scheduling, and there are a lot of software components to help you write your own applications as well. One is ilog scheduler .

This is the application area of "operations research". The OR society is doing a marketing campaign . There are a lot of packages for this type of scheduling, and there are a lot of software components to help you write your own applications as well. One is ilog scheduler .

Not intending to do self promotion, I'll point first to a competitor's product rather than my own:
Hivegroup's Honey Comb relies on the treemap technique from University of Maryland. This is far cooler idea than those lame heatmaps.

If you want a free try on your own data, you may also try my own version of the same stuff: ILOG Discovery.

ILOG Solver & Scheduler are mainstream commercial thrid party libraries in C++ based on the constraint programming paradigm. One of the major features is ILOG's automatic garbage collection heap, which is automatically deallocates memory (based on assumptions on program flow). To make this efficient, they skip all deallocations (using a longjump, rather than a return).

At first this may look like an elegant way to get rid of complicated memory management & garbage collection without loosing efficiency. However, in my personal experience, it is completely horrible when combined with pats that use the normal system heap. Specifically, when writing your own constraints, goals or deamons, it is practically impossible to use anything but ILOG's solver heap.

I gues this is one of the mayor reasons why they recently made a technology change and launched JSolver, a Java based counterpart.

--
Ninety-Ninety Rule of Project Schedules: The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent.

Qt has only one major problem: it's written in C++.

This is actually Qt's greatest asset.

But that one's a problem from which I have never seen a toolkit recover without the marketing dominance of Microsoft.

You should go out more often : RogueWave
Ilog

try to get an average-skill C++ developer up to speed on a project that's been under development for a year or so, and you'll be spending months explaining why you used the language the way you did

Too often true in practice, not true with Qt/KDE.

You know, that language that Linux, X, GCC, BSD, Apache, Bind, Sendmail and most of the rest of the civilized world's software is written in.

As I said, you should go out more often. There's a whole universe outside of the tiny rosy world of free software.

If you want to use a C library from C++ you can.

But it's highly suboptimal. Frankly it generally sucks big time.

The matrix is a little hard to read because there are so many languages in it....

And how many are complete enough to actually be used to develop a big application right away ?

The conclusion of my experience of 3 years helping to maintain Gtk-- and trying to develop with it, followed by 1 year of programming with Qt professionnally and with Qt/KDE at home is that Qt/KDE is, without a doubt a vastly better and more productive development platform than Gnome is at this time.

The language bindings point is totally moot, and after all these years and so few mainstream Gnome applications written in anything else than C, may be people should re-evaluate it. I wrote about it two years ago already, and as far as I can see most of my claims are still true.

When I started using Qt at work, I found myself to be more proficient with it after just a few days than I ever was with GTK+ or even Gtk--, where I constantly had to lookup either in some barely existant documentation or at the source code itself, or needed to add yet-another-wrapper for some strange struct I'd need.

A direct consequence of this is that whenever I wanted to write a patch for a KDE app, even fairly large and old ones (konsole, kmail), I could get a moderately complex feature done in just a few hours, over code I had never seen before.

Contrary to what you think, the level of entry of KDE for a programmer is way lower than for Gnome. Even a C++ beginner can produce useful code after just a few days of learning. This is not true for all C++ toolkits or projects, but it is true for Qt and KDE.

This is the reason why KDE's development pace is so quick, and why so many high-level applications like konqueror, kdevelop, or koffice could be written by teams of less than half a dozen people. Programming under KDE is just so easy.

I suggest you try it. You'll be surprised, as I was too when I switched.

You may want to have a look at ILOG JViews. You can use it to write map browser applets.