A while ago I asked for proposals for Eigen's mascot owl. We got excellent proposals from 5 artists and exchanged many e-mails on Eigen's mailing list. Finally I uploaded the best pics from each artist and we voted. The vote occurred on the mailing list in order to ensure that mostly people with a true interest in Eigen, and who followed the discussions, participate. Other than that it was open to anyone. 9 people voted.

Note that the drawings below are 'only' sketches (!)

drumroll...dzing! The winner, and personally my favorite, is the "Silly Professor" in the top-right of this pic (Copyright 2008 David Benjamin, licensed under CC-BY-SA):

We'll be sure make use of the 'todo' and 'bugs' owl sketches. The 'engineer' is also very nice for a documentation section on internals.

The very close second (only 1 voice behind out of 9) is this one (Copyright 2008 Ronnie Tucker):


Again, you can see here the other candidates.

According to this, the ISO are now calling a "standard" the Microsoft Office format (which is cynically called "Office Open XML"). I won't elaborate on the reasons why this thing is the opposite of what a standard should be, as this is clear to anybody not influenced by Microsoft.

What is interesting is that TeX, LaTeX, OGG/Vorbis, OGG/Theora, Perl, Python, PHP, Ruby, OCaml, are not standardized by any organization. Yet everybody knows that they are "self-standardized" by the free availability of extensive documentation and/or a by free-as-in-freedom unobfuscated reference implementation.

This shows that standardization organizations are no longer relevant in the software field. What really matters is free full documentation, free full implementation source code, and of course the absence of any patent risk. In other words, coming back to the fundamentals of what a standards is, what matters is evidence that any independent third-party can create and distribute a fully-conforming implementation. When this is the case, nobody needs an organization to certify that it is a standard.

That the ISO just proved itself open to the influence of special interests, is the consequence, not the cause, of its present irrelevance (again, in the software field). Since it is not needed anymore, nobody knows exactly what its mission is, what role it should play. Which allowed Microsoft to redefine that to its own advantage.

I think that the best move the ISO could now make is to acknowledge the limits of its own domain of application, which is the traditional industry, and to acknowledge that the software area is no longer such a traditional industry. In other words, ISO (and other standards organizations) should leave the whole software area, where they are not needed anymore.

Thinking further about this, here is perhaps the deep reason why in the end, software is beyond the field of application of standards organizations. This reason is that software is actually "just" mathematics. That was not obvious in the first decades of the computer industry, but it is becoming a concrete reality. Publishing the source code of a program is the equivalent of publishing the proof of a theorem. This is why the free software movement is changing the rules regarding standardization of software. In mathematics, once the proof of a theorem is published, there is no need for any authority to certify that the theorem is true. Everybody can independently look at the proof and realize that it is. And everybody can use the theorem without consulting its author. Likewise, once a free format specification is published with a free software implementation, there is no need for any authority (i.e. any standards organization) to certify that it can be used independently by any third-party (i.e. that it can be considered a standard). Thus, in the 21st century, a "standard" is just anything that has a full, free software implementation.

Today I'm looking for an artist who would be willing to draw Eigen's mascot. Eigen is a small but very powerful math library (linear algebra, i.e. matrices/vectors), and now's a good time for us to get a mascot as we are well on our way to releasing Eigen 2.0 in a few monthes, and are exceedingly proud of it :) Note that Eigen is getting more and more used in KDE (KGLLib, KTankBattle are two recent new users) and that the release of Eigen 2.0 will only accelerate that trend. It's also getting more and more users outside of KDE, some of whom have started contributing actively which is great.

The idea for our mascot would be an owl, and more specifically one "with ears" (i.e. a "duc"). I would like it to marry two aspects: it should be cute/cuddly, and it should still evocate the wisdom that owls are emblematic of (or at least an endearing and desperate attempt to look wise, from a little owl). A good approximation to what I have in mind is Archimedes, Merlin's pet owl in the Disney movie:



(see here for more). However, I would like it to be a bit more chubby/round and younger-looking. I would also like it to less serious. A good idea of the roundedness and of the attitude that I have in mind is found in the tux icons at TuxFactory, like this famous one:



However here I don't want the glassy aspect. I would like it with a lot of feathers and a fluffy aspect. Also note that in the above Tux icon, I like very much the silly eyes. I see very much our owl like that, and the attempt at wisdom could then be represented by a small wing raised like a teacher lecturing... or whatever idea you come up with.

In any case, if you'd like to contribute the Eigen mascot, please send your proposals to: eigen (at) lists tuxfamily org. It would be much appreciated! After we hopefully get a few proposals, we'll see which one is the most popular. Do not hesitate to write to us with only a sketch, so you can ensure early that people like what you're doing.

This blog entry is plainly advertising for a little French nonprofit forge, TuxFamily. Well I hope it's OK to advertise them since they're working in their freetime and offer their services without charge. They do not even use ads to make money.

If you've been looking for hosting for your Free Software project, look no further, for this is the best forge that I know:

• It itself is entirely Free Software


• The server is damn fast. Check how Eigen's website loads fast.


• It runs PHP4 and PHP5 so you can easily put a wiki online. They even have a tutorial (French wiki; apparently it's not yet translated). They also have other features like SQL server, download area for large files (up to a gigabyte or more)...


• Not only the web server is fast, but SVN is also the fastest I've seen: "svn up" and "svn ci" take only a fraction of a second. They also support CVS... and Git !


• Likewise, the mailing lists are the fastest and most reliable I've seen. I rely on tuxfamily for Eigen's mailing lists, and the mail is consistently delivered within a few seconds.


• It does not use any ads. No ads on your project website, no ads on their website, no ads in the mailing lists...


• The crew is awesome and very low-latency... all my requests have been handled within hours at most, and often within minutes.

That's what I've known for a long time and made me think of Tuxfamily as 'great'. But recently something made it move to my 'awesome' category. I'm a mathematician and my work consists partly in editing LaTeX files with colleagues. I've been looking for a forge to host collaborative math projects, i.e. doing math research in the same way as Free Software is done, just replacing C++ by LaTeX. SourceForge refused, but Tuxfamily accepted.

Lastly, Tuxfamily is running a donation campaign. It's their first one in 5 years of existence, and all the more justified since they don't use ads.

Now that KDE 4.0.0 is tagged I guess it's OK to divert developers attention to KDE 4.1 stuff :)

So I just released Eigen 2.0-alpha2. Source tarball, Browse SVN.

Besides a ton of improvements over alpha1, the main novelty is that there is now quite complete API documentation.

New features since alpha1 include: ICC compiler support thanks to Gael Guennebaud, full enforcement of constness, support for row-major matrix storage (column-major remains default), and tons of API improvements and new methods.

Now's the time where you can really start using Eigen2 in your own project, if the current feature set is enough for you. I'm very happy with the architecture, and benchmarks show that it's very fast. According to sloccount there are 2,234 lines of code. Which is very, very little for what it does.

In fact, there are not so many expression-templates-enabled libraries out there:
- Blitz++ is of course great but is not a linear algebra library, so Eigen2 does not compete with it. Blitz++ is a general array library, and focuses on dynamic size while I want fixed size to be treated on an equal footing.
- TVMET only does fixed-size, does not allow expressions to be lvalues, etc., while having 5x more lines of code than Eigen2 (granted, it has some functionality not yet present in eigen2 such as applying a function to each coefficient). That said I have a huge respect for TVMET as it is by reading its source code that I learnt expression templates.
- Boost::uBLAS does not fully take advantage of expression templates. It treats them as a mere optimization that can be enabled/disabled at compilation. While expression templates are a great optimization, I believe that the most interesting thing about them is what they allow in terms of API design. Operating on the rows of a matrix should be as simple as

matrix.row(i) += factor * matrix.row(j);

This is what Eigen2 allows. This way one can write C++ code that really looks like pseudocode, and at the same time that's optimized. This is the real beauty of expression templates, and I regret that Boost::uBLAS doesn't take advantage of it. Another thing is that, like any BLAS, Boost::uBLAS only provides very basic functionality and one then needs to use another library for more functionality (such as inverting a matrix). By contrast, Eigen aims to be self-contained to cover all the usual needs of applications.

Update:I just found this: apparently fixed-size matrices and vectors are slow in uBLAS and for fixed-size they recommend to use TVMET instead! It's a small world.

I hope to have convinced you that by contributing to Eigen, you would be contributing to a very exciting project! For this is the motivation of this post: I need help!

While the Core module is quite complete, there are at least 6 more modules that we want to have for Eigen 2.0. I don't have time to write them all! So here is a TODO.

I would like very much to find volunteers quickly as the KDE 4.1 feature freeze is probably not too far away (though at least 3 monthes away) and if Eigen2 is good enough soon enough, it might be useful for several very exciting things in KDE 4.1, such as Step.

Then, a major user of Eigen2 will quite probably be KOffice 2.1, but this leaves us more time. Interestingly, the most advanced feature that KOffice/Krita requires, namely sparse matrix support, is also what Step requires. So, to any potential volunteer: by doing that, you will be a hero to both KOffice and KDE-Edu!

Just a quick notice: I've released a first alpha of Eigen2; very preliminary website here (no documentation for now), source tarball here.

It's very far from being feature-complete. Only the Core module is there, while several others are planned.

That's all for now, I don't want to distract the KDE community too much from the upcoming 4.0 release :)

I am now running a full KDE4 session, from a svn checkout from yesterday. That's 10+ days after the tagging of beta3, and at the current pace of bugfixing, this means a lot of improvements.

So what's it like? Here's the obligatory screenshot. You can see Okular annotating a .djvu file (of course it also works with .pdf files) and Marble, which is a bit like Google Earth except that it can be embedded in any KDE4 app, which opens endless possibilities. You can also see the Battery plasmoid, which reacts instantly when you plug/unplug your laptop, and the Pager plasmoid, which works just as in KDE3. KWin defaulted to using OpenGL for compositing, and it works great here. Slamming the mouse to the top-right corner triggers the very useful Present Windows effect.

For me it's all perfectly usable, so I'm staying under KDE4 full-time. Not only to help with beta-testing (I already filed this bug report), but really because it already is stable and complete enough for me to use as my main desktop. I'm still using some KDE3 apps in my KDE4 session, but that's not a problem at all -- though of course it would be nice to use only KDE4 apps eventually.

On another note, Eigen2 development has been very fast recently, but more on this later -- for now the top priority for us all should be to help as we can to get 4.0 in shape, and Eigen2 will only be used in KDE 4.1 and KOffice 2.1. So I try to compensate for my current non-contribution to the 4.0 effort by doing some beta-testing, bug-reporting, and encouraging you all to do so :)

On saturday I decided that after all TVMET wasn't the appropriate starting point for Eigen2, so I restarted Eigen2 from scratch.

I started coding on Sunday, and today I made the initial commit to KDE's SVN in w /branches/work/eigen2.

I'm very happy about how things have been going since this restart. The basics are already there. Eigen2 already has matrices and vectors, both fixed-size and dynamic-size (reusing the CRTP trick from Eigen1), and of course expression templates (ETs). Non-square matrices are handled, and the ETs can be lvalues, not just rvalues.

It's funny how none of the existing libraries for vector and matrix math seems to do all what one might want. Each of these libs (Blitz++, MTL, LAPACK, GSL, TVMET, GMM++...) is specialized for certain needs. Usually, an app will choose the most suitable one for its needs, and be happy. But KDE is a huge meta-project with lots of sub-projects, so it has a very broad range of mathematical needs, which is not covered by any of the specialized libraries.

Writing from scratch such a general math library would take many man-years. However, what one can do is to merge existing libraries into a single one.

A killer feature that we absolutely want is expression templates. It's a strange C++ technique that allows to do things like a = b + c without paying the cost of having a temporary object allocated on the stack and then copied into a. Basically, it allows to use natural mathematical notation without any overhead. It even allows things like

matrix.row(i) += matrix.row(j)

which would be impossible otherwise.

The best expression templates for a matrix library are currently found in TVMET. Unfortunately, TVMET has been stagnant for 2 years and has been very little used by other projects, which is probably due to being too abstract, aiming too much for theoretical perfection.

For Eigen2, I decided to use TVMET as my starting point, instead of Eigen1. Of course, the contents of Eigen1 will be incorporated into Eigen2 as soon as possible. However, for now my work has been focused in shaping TVMET for my needs. I've converted it from autotools to CMake, and I've removed tons of stuff that I don't need, shrinking it down from 12000 to 7000 lines of code, and I've still room to shrink it further, and I've already added some good stuff from Eigen1, such as sane fuzzy comparisons. I'm currently porting the unit-tests from CPPUnit to QTestLib, and by the way I'm improving them a lot now that there are sane fuzzy comparisons.

What's next? Once I'll have fully reshaped TVMET and incorporated Eigen1 into it, I'll have a working Eigen2 for tiny (i.e. fixed-size) vectors and matrices. For dynamic-size objects, both dense and sparse, I'll wrap GMM++. In order to make this possible, the expression templates from TVMET will have to be adapted, as for instance loop unrolling will no longer be possible.

It's a very exciting project that is bound to fill a very bad gap in the current existing software. It requires only knowledge of pure C++, and vague notions of matrix mathematics. Your help is more than welcome, as there's a lot to do. So don't hesitate, join me: eigen at lists tuxfamily org.

Carsten asks me to blog for him as PlanetKDE lost his blog:

Moin

Many new icons got in as well as some new features. Here you can see the new Short Table which is used a lot in (german) schools. As you can see some icons are missing and some need to be tweaked. But in general it already looks quite nice. All icons are rendered directly from SVG by the way!



Let me add that a new artist recently joined us and started contributing icons to Kalzium: Noémie Scherer. On the above picture, at least the icons for B, C, P, I are by her. She also draw icons for other elements that don't appear on this Short Table.

Update: Screenshot updated. Due to bad CMakelists some icons were not displayed. Also the image was scaled which was bad.

I've been quiet lately, partly because I've had to spend most of my time on my thesis, and partly because I've done all my coding in Avogadro (no real website yet), which is not yet in KDE's SVN. If you read this story showing the new Kalzium3D features, maybe you'll be interested to know about libavogadro. This library initially took the kalzium3D rendering code but set much more ambitious goals, with currently 4-8 hackers including a promising SoC. There are immediate plans to port Kalzium to libavogadro; however libavogadro won't reach API stability in time for KDE 4.0 so we'll probably import a snapshot inside the Kalzium tree in the next days.

A new thing that libavogadro does is to draw labels on atoms. Rendering text inside an OpenGL scene is not straightforward. The problem is that in an opengl scene, you typically can't control the color of background. And if the text color is too close to the background color, then it's not readable. A bad workaround is to paint a semi-transparent dark rectangle behind the text. But in many occurences that feels ugly.

So a better solution is to draw a black shadow around the text. Just like the text below the icons on your KDE 3.5 desktop background. AFAIK, Qt does not yet provide that functionality, which is why KDesktop has its own code for that.

I initially tried to do it with QGLWidget::renderText, achieving the shadow by painting the text multiple times. Alas, renderText is not very fast, and multiple renderText calls are even slower. I got something working, but the framerate was divided by a factor of 5 (with Qt 4.2.3 and 4.3-b1). Too slow!

So I took my old TextRenderer class that I had written for Kalzium, and improved it to do shadowed text. This was achieved as follows: use a 16bpp GL_LUMINANCE_ALPHA texture, paint with Qt the character and read the luminance channel directly from the resulting bitmap; while the alpha channel is obtained by applying a trivial convolution filter (much like what KDesktop does, see above link). Characters are rendered on the fly whenever they are first needed, and are then cached and managed in a QHash.

The code is in avogadro's SVN tree at sourceforge but it's still very unclean and comments/docs are missing.

Obligatory screenshot (see how the shadow is necessary for readability on the white Hydrogen atoms):


This 35 frames-per-second is on my laptop with software-only rendering (mesa-swx11) and the highest level of detail. Disabling the labels on the atoms only increases the framerate by +10%, which is not too much if you consider how slow texture-mapping is on software-only systems.

Eigen 1.0 is released! This project started in July when we (that is, a handful of KDE developers) realized that we had a common need for some math functionality that no library out there seemed to cover reasonably. Sure, there are many linear algebra libraries, but they are either too small/amateurish, or too big/professional and focusing on heavy scientific stuff that we don't need. People objected (rightly) that adding a big dependency would be frowned upon by distro maintainers. So we decided to start our own linear algebra library, Eigen.

5 monthes later, it's there. If you're looking for a lightweight library for vectors, matrices and related math stuff, please give it a try. We have fixedsize classes, as in "float v[SIZE];" and they're very fast and specially optimized for low sizes (<=4). We also have dynamic-size classes, which can be useful if you're developing e.g. a spreadsheet and want to be able to solve any system of arbitrarily many linear equations. And we have special classes for projective geometry, which can be useful in OpenGL apps, as was demonstrated in my previous entry.

By the way, and Eigen is very fast with GCC, whereas some other linear algebra libraries will tell you to use the intel compiler instead. The issue here is that GCC has problems with loop unrolling. In particular, GCC often fails to unroll nested for loops, which is annoying e.g. for matrix product, see this bug report. In Eigen, this problem is worked around by manually unrolling loops in fixed-sizes up to 4 (which are the cases where loop unrolling is wanted).

It looks like Eigen 1.0 will be out in 2006 as promised. For this occasion, I have fixed a small example program. Since the beginning, one of the primary goals of Eigen has been to provide the math functionality that is useful in OpenGL apps. And one of the most common problems when writing OpenGL apps is, how to let the user freely move the camera around? Representing the camera orientation by 3 angles just doesn't work, and leads to the gimbal lock problem. So the best solution is to represent the camera position and orientation by a 4x4 matrix and pass it directly to OpenGL. The question is then, how to generate this matrix from the user input? This is where Eigen comes into play. Here is the GLWidget::mouseMoveEvent() function from the Eigen example program:

void GLWidget::mouseMoveEvent( QMouseEvent *event )
{
    QPoint delta = event->pos() - m_lastPos;
    m_lastPos = event->pos();
    if( event->buttons() & Qt::LeftButton )
    {
        m_cameraMatrix.prerotate3( - delta.x() * ROTATION_SPEED, AXIS_Y );
        m_cameraMatrix.prerotate3( - delta.y() * ROTATION_SPEED, AXIS_X );
    }
    if( event->buttons() & Qt::RightButton )
    {
        m_cameraMatrix.prerotate3( - delta.x() * ROTATION_SPEED, AXIS_Z );
        m_cameraMatrix.pretranslate( delta.y() * TRANSLATION_SPEED * AXIS_Z );
    }
    if( event->buttons() & ( Qt::LeftButton | Qt::RightButton ) )
        update();
}

This lets the user rotate around by drag & drop with the left mouse button, and tilt and move forwards/backwards by drag & drop with the right mouse button. Then the paintGL function looks like

void GLWidget::paintGL()
{
    glLoadMatrixd( m_cameraMatrix.array() );
    drawScene();
}

Obligatory screenshot:

Bruce Perens has just posted this petition:

Protest the Microsoft-Novell Patent Agreement

In Kalzium's 3D viewer, a problem was that when you loaded a molecule, the default viewpoint was not always optimal, sometimes totally unreadable. For instance, look at this molecule of L-tryptophan :

Of course, Kalzium always allowed to freely rotate around the molecule, so after some mouse effort, you could get that:

But then, a second problem appears: depending on the viewing angle, double bonds can look like single bonds. In the above pic, one should see 6 double bonds. This even mislead some people into believing that our molecule files were wrong! So I sat down and figured that the first thing to do was to perform a linear regression to compute the best-fitting plane for the molecule. Once we know that plane, elementary geometry allows to find a nice viewpoint and to orient the multiple bonds in a convenient way. So I implemented linear regression and a computeFittingHyperplane function in Eigen, and reworked Kalzium's 3D viewer to make use of it. Result:

I haven't had to do any manual rotation for this screenshot, this is the exact viewpoint you get when you load the molecule. Also note that now the 6 double bonds clearly appear. Maximizing the window, I got this.

About speed: for these screenies, I take the high-quality mode, and get 56 FPS on my software-only (no hardware acceleration) 1.66 GHz Intel Core 1. In low-quality mode, I get 178 FPS, and at this window size, the visual difference is not too big. Even on Carsten's laptop, it runs OK ;)

Update: as a comment pointed out, the molecule file is wrong, there is one hydrogen atom missing and one double bond too much. This was a bug in the (very old) molecule file that I used, and has been fixed since in the BlueObelisk project.

Here's a rough translation of a few lines from Levinas's 1934 essay, Quelques reflexions sur la philosophie de l'hitlerisme (3 paragraphs to the end) :

An idea, by propagating, detaches from its starting point. It becomes, despite the unique accent given by its creator, a common good. It is anonymous. The one who accepts it becomes its master as much as the one who proposed it. Thus, the propagation of an idea creates a community of "masters" -- it is an equalization process. To convert, or to convince, is to create oneself peers. The universality of an order in the occidental society always reflects this universality of truth.

But force is characterized by another kind of propagation. The one who exercises it doesn't detach from it. Force doesn't dilute into those who are subjected to it. It remains attached to the personality or society who exercises it, widening them while subjecting the rest to them.

Now replace "idea" by "Free Software" and "force" by "Non-Free Software".

Update: improve translation, replace "strength" with "force".

Eigen 0.9.3 was released today with important compilation fixes. Because Eigen is templates, compilation problems are difficult to detect, so before the next release I'll add unit-tests specifically for that.

The new permanent website of Eigen is here:

http://eigen.tuxfamily.org

Also we got a mailing list: eigen at lists tuxfamily org. To subscribe, send a mail with subject "subscribe" to eigen-request at lists tuxfamily org.

Eigen 0.9.2 is here. Lots of sparse improvements since 0.9.1, plus one "big" feature: functions for linear regression analysis. I've been careful to write hopefully good documentation for that. By the way, did you know that doxygen allows to use LaTeX to produce png's of math formulas?

Eigen got a new website, entirely doxygen-generated. Because it's doxygen-generated, it would probably not be a good idea to host it in KDE's SVN, so I'm registering a project at TuxFamily. But there really are some good sides with using doxygen to create a website. For instance, the LateX png feature provides a cool way to show e-mail addresses while protecting them from spam!

On the cool side, it seems that one big scientific (non-mathematical) Free software project is considering moving to Eigen ! I'll handle the porting soon and will let you know once it's official :)

I'd like to draw your attention on this blog post, which I found interesting:

http://log.ometer.com/2006-11.html#7

In particular, he argues that the Novell FAQ "tries to weasel out the spirit of the GPL". I tend to agree with him, but I don't have the necessary knowledge to have strong opinions on this issue.

Eigen 0.9.1 has been released today. It's a lightweight C++ template library for linear algebra: vectors, matrices, solving systems of equations...

Eigen provides:
* classes for vectors and matrices, in two versions: fixed-size and dynamic-size. The fixed-size classes are zero-overhead and never cause dynamic memory allocations. The dynamic-size classes provide better flexibility. Both versions use the same C++ code, thanks to a C++ trick known as the Curiously Recurring Template Pattern.
* classes for easy solving or systems of linear equations. Again, both fixed-size and dynamic-size versions are provided.
* classes for directly handling LU decompositions.

Kalzium has already been ported to Eigen, which will allow for more 3D coolness in the molecule viewer. A handful of other KDE apps are also considering using it. But, as Eigen is pure C++ with no dependency at all, it could very well be used by non-KDE apps, which is why we put it in trunk/kdesupport.

We plan on a 1.0 release within one month. To all app developers with a need for some math functionality : now's the time to give Eigen a try!

Website: http://edu.kde.org/kalzium/eigen/index.php
API documentation: http://www.math.jussieu.fr/~jacob/eigen/dox/
Source code: http://websvn.kde.org/trunk/kdesupport/eigen/
IRC: #eigen on freenode

Digg this entry