20100514

GSOC 2010 Redirection

Hi Folks,

I just thought that I would put something up here to redirect queries about my GSOC 2010 project entitled "Neon Support for FFTW". Since my primary blog (the perpetual notion) has several completely unrelated categories, I've set up a dedicated blog for this GSOC project to avoid any potential confusion.

So please visit gsoc2010-fftw-neon.blogspot.com for any GSOC-specific information.

20100327

Musical Memory

Here's a blog post that diverges from my usual ho-hum, and will hopefully appeal to my non-technical readers.

Do you have a certain episode in your memory that is always triggered when you hear a particular song? Was the significance of that moment so intense, and did the song fit so perfectly with that instance, that the two will be forever paired in your mind? If you do, I certainly hope that the memory was a good one.

Mine certainly was, and the song was "Let's Spend the Night Together" by The Rolling Stones.

Although the name of the song might allude to some incredible one-night romance, that's not exactly the case. The reason that this song is so strongly imprinted in my memory, is because it floods me with the same feeling I got when I became a dad for the first time. Indeed, the moment was the night after my son Jules was born.

We were at saint Mary's hospital in Montreal, and all of us (Erin, Bo, Nora, Jules! and myself) all had an extremely long night with the labour, and subsequent early morning delivery (especially Erin!). After taking a few hours to absorb the initial wow-ness of the new life we brought into the world, we were completely exhausted, and slumbered through a large portion of the day and evening. As often is the case with hospitals, they required us to spend an extra night in observation to ensure that both Erin & Jules were in good enough health to be released the following day. Jules, like any newly born baby, spent most of his time sleeping, until later on that night.

It must have been around midnight or so when he woke up and was crying something terrible. Erin and I checked him out, and, yes, he needed his first diaper to be changed. On one hand, Erin had never before changed a diaper - ever! And on the other hand, I hadn't changed one in about 10 years (I had some previous babysitting experience). Needless to say, we were both a little nervous.

So we disposed of Julien's dirty work, and carried him gently over to the wash basin and gave him a quick rinse with some warm water, all the while singing something - anything! It was actually the first song that popped into my head. I had been on a Stones kick for a good week before that. So Erin and I were both singing this Rolling Stones song to n-hour old Jules. The words go something like "let's spend the night to-ge-ther, now I need you more than e-ver, " and those were probably all the lyrics I could remember at the time, but it didn't matter.

After some initial clumsiness, we securely fastened the new couche on to Jules, and curled up on the same hospital bed - something that is typically frowned upon - but we just did what came naturally. Jules, Erin and I fell back asleep, in comfort, a few moments later.

Today I was putting in some overtime studying for my next exams - Optical and High Speed Communication. This song, along with the thoughts and memories that it evoked, was motivating me to study hard the whole day, because I know what's waiting for me when I'm done.

Dad is coming home soon.

20100306

PsqlDroid: A Native PostgreSQL Library for Android

I was a bit bored with my current project, and was looking over some of the work I did recently, and remembered that I ported PostgreSQL to Android a while ago. After gaining approval to make my work publicly available, I put it up on Google Code. So be sure to check out the PsqlDroid project page if you're interested.

There is still a considerable amount of work to be done to publish Java bindings in the Dalvik VM (probably with with the existing PostgreSQL JDBC driver).

Any help is appreciated!

20100302

Apple is Suing HTC for Software Patent Violations

Recently when I wrote a small rant about software patents, I guess I should have also given a thumbs up to HTC, the company that manufactured the Nexus One and many other Android handsets.

On the other hand, it seems that Apple is not too pleased with HTC at all.

Apple has essentially patented a device driver (i.e. software). Read the first 30 bytes from patent #7479949, and you will quickly realize that it is moot. Here are those 30 bytes for your convenience:

"A computer implemented method" ...

Although many people think that Apple has a hardware patent on multi-touch / capacitive touch screens, they do not, just as I suspected (at least according to patent #7479949). I also suspect that a 3rd party company was responsible for designing and fabricating "Apple's" multi-touch screens, although Apple was certainly not the first to demonstrate multi-touch.

Naturally, it is in the best interests of that 3rd party company (whoever they are) to sell more of their touch screens but that is something which Apple has wholly tried to prevent (via software patents).

For the (approximate) 6.4 billion people in the world who do not live in the US - fear not - you have a legal right to buy a multi-touch enabled phone from a company other than Apple.

For those who live in the US... unfortunately, you might have to edit a few lines of code to get multi-touch in a "legal" way. If Apple really feels like it, they might be able to bar HTC from enabling multi-touch support in Android for all devices sold in the US, although seeing as how it is a free OS, there is little preventing consumers from enabling it themselves. Apple will also undoubtedly try and gouge HTC for "lost revenue".

Good luck with that, Apple.

Hopefully, the USPTO will flag this case like many others and revoke Apple's software patents.

20100222

A Distinctive Lack of Simple Complexity in Java

Simplicity is a wonderful thing. When problems become increasingly complex, sometimes a simple action, like going for a run or turning off the radio, can often simplify the solution.

Java generally makes programming tasks simple; there is "no need to worry" about memory allocation and garbage collection, and it "just works" on basically any platform. However, unlike its (arguably) simpler counterpart C, Java does not support complex numbers in the standard runtime. There are some independent efforts to create a generic Complex<T> class, which would be necessary for completeness in Java's Object framework, but the primitive complex numeric types are noticeably absent. As far as I'm aware, it's also impossible to define a new native type in Java without modifying the JRE / JDK directly. Why Java didn't add complex numeric types from the beginning is a mystery to me. It might have something to do with Windows compatibility, but I can't say that for certain.

Who uses complex numbers in software anyway?

Although it's clearly simple in any language to define a set of functions (methods) and structures (classes) for dealing with complex numbers, if the API is defined at the language level, then all users of that language can share the advantage of a common, complete, and compatible library for their code. Complex numbers are used heavily by engineers and mathematicians. Generally any mathematical tool (such as Matlab, Mathematica, or GNU Octave) requires complex number support for completion. Complex number support is also heavily used by more specific electrical, RF, signal, and mechanical engineering software - essentially anything that deals with a time-variant oscillatory system. Mobile phones do complex math in the baseband processor, so one could say that we ALL benefit from standardized complex number support.

Personally, I have been hacking with the USRP2 (Universal Software Radio Peripheral) from Ettus Research, Inc, and have been using a custom Java / JNI library to interface with it. Since the data that the USRP2 receives and transmits is in the baseband domain, it is generally always complex. The C / JNI portion of my code can handle complex numbers natively, but when I use my Java interface, my options were limited. I either needed to access the data real and imaginary data independently as float or short variables and arrays, or I needed to write a simple Java class for complex numbers.

Why does native complex number support in Java matter?

Consider the overhead of using a single java.lang.Integer object. First of all, every Integer class must inherit from java.lang.Number, but also from java.lang.Object. Static (class) methods and non-static (instance) generally do not introduce much overhead, since they only exist (maximally) once per Class and share everything but their instance information with other instances. However, for each Integer instance, there exists a non-trivial number of fields, including but not limited to i) a hash code, ii) a reference to the Class, iii) synchronization primitives for wait(), notify(), etc, iv) various flags indicating things like finalization, constant status, etc. There are probably also some additional instance fields inherited from Number.

Now, consider the simplest of Integer collections: an Integer[] (array of Integer objects). Aside from the (generally) 4-byte value of the Integer itself, there are undoubtedly at least an order of magnitude more bytes just for instance information of the Integer object (hash, references, synchronization primitives, flags, etc). Lets assume that there are 28-bytes of additional instance information. For an array of 512 Integer objects, the approximate storage requirement is (28 + 4) * 512 = 16384 bytes, which dramatically exceeds the (approximate) 2048 bytes that a simple int[512] would require.

In order to support a complex Integer type, for the same array length, there would be approximately 32768 bytes versus the 4096 bytes that would be required in C. In actual JRE implementations, there may be some optimizations for arrays of Numeric objects, but when all is said and done, each element in such an array must still be a fully qualified Object upon access.

In C (GNU C at least), any numeric data type can be augmented with the complex keyword, and I think that Java would benefit greatly from introducing the complex keyword into the language specification as well. Naturally, there would need to be special consideration made for various things such as division, casting, etc, but overall it should not be very difficult.

Posix and GNU C take a very simple and elegant approach to complex numbers. They define a special variable, I (and _Complex_I), as well as a set of standard math.h extensions. However, Posix C only defines functions for dealing with double and float complex numbers (much like the majority of functions in math.h). In GNU C, one can additionally use any numeric type with complex numbers. The storage space doubles for a numeric type that is declared complex, with the real and then the complex portion being allocated contiguously. So if I define a complex int x, then & ( __real__ x ) == & x, and & ( __imag__ x ) == & x + 4, while sizeof( x ) == 8. The C language takes this allocation into account with arrays and pointer indexing as well, so & x[5] == & x[4] + 8, and so on.

Although I really have no time to work on this personally, at some point if I do have time, I would probably modify JamVM and the GNU Classpath to implement natively supported complex numbers. With a simple open-source implementation as a reference, putting together a JSR for official adoption would probably widely accepted and welcomed by the majority of the Java community.

If anyone is aware of an existing JSR for the complex keyword and associated modifications, classes, etc. Please let me know. Otherwise, if anyone is interested in collaborating on this, please leave a comment below.

Likewise, I'm fairly certain that C# does not support native complex numbers, although Python might. So, if anyone would like to hack Mono and get native complex types built-in, please leave a comment below.

20100215

Java and getResource()

I'm posting this so that somebody else might find it useful, and I found my answer here, just for reference.

When designing Java code that is to run both as jar-applet and as an application, and you need to load some file (image, text, whatever) that lives with your code (e.g. from the same jar file, or when you're debugging with Eclipse) it's necessary to use getResource() while ensuring that your resource lies in the classpath.

However, ensuring that the resource is in your classpath is not enough - by any means.

Here's a simple example where getResource() does not work as expected. if I want to read in a text file stored in "resource/text/Hello.txt" and if "resource" is in my classpath, then I should use something like


import java.io.*;
import java.net.*;


public class Hello {
public static void main(String[] args) {
URL url = getClass().getResource( "text/Hello.txt" );
System.out.println( System.getProperty( "java.class.path" ) );
try {
BufferedInputStream bis = new BufferedInputStream( url.openStream() );
byte[] buffer = new byte[16];
int br = -1;
br = bis.read( buffer );
while( br != -1 ) {
System.out.println( (new String( buffer )).trim() );
br = bis.read( buffer );
}
} catch( Exception e ) {
e.printStackTrace();
}
}
}

Run the above example with

java -cp resource Hello

However, this just fails miserably when the Hello class is not part of the default package. Just try inserting "package some.random.pkg;" at the top of Hello.java and see what happens. The reasoning for this is slightly backwards if you ask me. The ClassLoader that Hello.class references does not have the visibility to load eternal resources, and I'm not sure if it has the ability to load a resource in it's own package for that matter. What you'll see is that url is always null when you use getClass().getResource() when Hello is in a non-default package.

According to Class.getResource() API, this shouldn't actually happen, since it's only specified to look in the classpath.

The only way that I have found to actually load a resource is to use the following:


package some.random.pkg;
import java.io.*;
import java.net.*;

public class Hello {
public static void main(String[] args) {
URL url = Thread.currentThread().getContextClassLoader().getResource( "Hello.txt" );
System.out.println( System.getProperty( "java.class.path" ) );
try {
BufferedInputStream bis = new BufferedInputStream( url.openStream() );
byte[] buffer = new byte[16];
int br = -1;
br = bis.read( buffer );
while( br != -1 ) {
System.out.println( (new String( buffer )).trim() );
br = bis.read( buffer );
}
} catch( Exception e ) {
e.printStackTrace();
}
}
}

Run the above example with

java -cp .:resource some.random.pkg.Hello


So, I'm not exactly sure what the point of the ClassLoader visibility braindamage is, but it seems fairly pointless to me. At least there's a workaround.

20100127

Eyeborg: My Thesis Project has Begun

The wheels of academia have begun to turn and I've been approved to start my thesis project in the Center for Wireless Communication (CWC). I can't give out many of the technical details yet, but let me just say that it's insanely cool and has to do with the Eyeborg Project.

If you've never heard about the Eyeborg Project, please check out their channel on vimeo and visit their homepage (www.eyeborgproject.com).

20100119

Fake USB Flash Drives

Hi folks,

For the last couple of years, there seems to have been a huge influx of so-called 'fake' USB flash drives. Why they are called fake, is
  •  they report a storage size larger than they can actually store
    • maybe they use compression internally
    • maybe they just allow data to be overwritten without warning
  • they often cannot be used as a bootable USB device
I am one of the unlucky many who did purchase one of these devices, and found out something was strange with it when it would not boot an Ubuntu or Gentoo Linux LiveUSB installer.

Although I purchased my 4GB USB storage device a long time ago, I always keep electronic records of my purchases. This unit was purchased on Amazon.de, from a 3rd party reseller called MemoryWorld.de . I highly suggest that Amazon should blacklist this vendor for selling fake or counterfeit USB flash storage devices.

My particular device has USB vendor ID (VID) 2008 and USB product ID (PID) 2018. I'm not really sure where you would look for this in Windows, however, in Linux (using lsusb) this device will show up as 2008:2018 .

I'll post some detailed photos of the device later, but I just opened the casing and the USB transceiver is an UHC2008. The company that makes this is called "Shenzhen Sea Song Microelectronics Co., Ltd". The label on the storage chip is SFO8BGTP. I'm not quite sure who this belongs to yet though.

Just in case anyone has the same device, there are some instructions for how to fix and verify the device here. Unfortunately, the instructions assume that you are a Windows user. Hopefully I'll be able to find out if there is an equivalent tool for Linux.

20100108

Picasa for Linux, Multi-touch, and Software Patents in General

I should state this clearly at the beginning of my post, just so I don't come off the wrong way. I do appreciate everything that Google has done and how they have contributed back to open-source software. The same is for Apple - I am grateful that Apple helped to revolutionize the user experience and to inject a fusion of art and technology in their designs. However, there are some issues (mainly revolving around the concept of software patents) that prevent many wonderful, Google-created applications from being wonderful on Linux.

Three examples come directly to mind:

1) Picasa for Linux: does not support viewing or uploading of video files.
2) Android: does not have a 'playmp3' binary when built from source.
3) Android: does not support mulit-touch (using the commercial ROM). update: Newer Android devices do support Multi-Touch, with open drivers. Thanks Google!

With respect to my first issue (and I'm sure that anyone who has a child and a Cannon point-and-shoot digital camera will agree with me) I make a heck of a lot of videos. In some cases, I make more videos than still photos. Picasa (for Linux) does not support videos at all because many video codecs (although there are free implementations) require royalty payments to be made to some patent holder. Maybe Apple and Microsoft do make these royalty payments, and thus can provide the video codec binaries to applications for their platforms. I can't even use PicasaWeb to upload videos of my toddler, and in that case Google wouldn't even need to redistribute any royalty-encumbered software. There's something wrong with this, but let me address the other two points before beginning my rant.

As for the second issue, I believe its a similar situation. Perhaps Google does make royalty payments to Fraunhofer (the 'owners' of the mp3 format patents), which allows them to distribute a device with an mp3 decoder. I would certainly hope that Fraunhofer provides Google with the code, because if they're just using ffmpeg or lame, then there is definitely something wrong with that situation as well.

Lastly, with respect to the third issue, Apple holds patents for mulit-touch and has requested that Google intentionally cripple the Android UI. I can fully understand that a patent could and should be granted for the physical device that senses multiple points of contact, but as far as Apple having a patent on software to read that device (i.e. the driver) and software to interpret that device for a user-interface, that's just absurd.

What all of these issues have in common, is that they all revolve around the same concept: the patentability of software. Along with 90% of the world, I do not believe that software should be patentable. Typically, a patentable 'device' should be 1) novel, 2) useful, and 3) non-obvious. In at least 50% (but more likely 80 or 90%) of software 'patents', they rarely satisfy any of those three conditions, at least in this day and age.

Historically, patents were introduced in order to encourage innovation. A company bringing a new invention to the world was awarded the patent in order to prevent others from wasting their time trying to come up with the same, patented product. This encouraged competitors to come up with different or better inventions. A company awarded a patent was therefore awarded adequately for their hard work, with their physical design being preserved for a limited time. After that limited time, competitors could begin to offer similar inventions on the market. Seems pretty fair to me.

However, software (in the truly scientific sense of the word) is math. Math is a collection of ideas. Patenting ideas has never officially been supported by any patent system. I really think that the only law that should apply to software is that of trade-secret and copyright. Surely, if one company copies the software of another and pawns it off as their own, then that is illegal.

On the other hand, if another entity can legitimately show that the software (be it a signal processing algorithm or device driver) had been cleanly reverse engineered, then that other entity should legally be allowed to sell or redistribute their version of the software, especially if it more adequately suits some population of recipients or users (i.e. if it fixes bugs, works faster, etc). In the same sense, I don't consider it a crime to decipher encrypted transmissions.

I find it tragic that authors of free software are not allowed to distribute their work, and help others, because the patentability of software is accepted in 2 countries on earth. I do believe that physical things should be patentable if they are novel, unique, and non-obvious, but I don't believe that inquisitive minds should be limited.

20100101

Could Google's Nexus One be Available as Soon as January 5th?

Just as many of you have undoubtedly read, Google released a new handset before Christmas to all of its employees for testing. The device is called Nexus One. A decent video introduction can be found here. One thing to note is that the 3D gaming demo (2nd video) shows Qualcomm's logo, which leads me to believe that the Nexus One most likely packs a 1GHz Snapdragon SoC under the hood. I'm very interested to say the least and am eagerly awaiting the rumored January 5th release date.