20101001

Smoking Laws in Ontario, Quebec

On a different note, I thought that I would talke about an idea I had for an amendment to the existing Ontario bylaws that prohibit smoking in public buildings, places or private automobiles with a child present. It is illegal in most municipalities in Ontario. It's getting better in Quebec, but Ontario is a bit further ahead. The biggest problem, in my opinion, is smoking in the home around children. Certainly, there have already been numerous studies that indicate without a doubt that smoking in the home around children is harmful, but why isn't it illegal? I suppose that one could argue that it interferes with a persons rights... to smoke... and ... err... slowly poison their children (!?). Ridiculous, right? In some cases such as mine, it isn't even a volountary decision, and I would really prefer not to have any member of my family, but especially my son, slowly poisoned.

In Montreal, it's common to rent and live in small buildings where each floor is a residence in itself. In some older buildings, smoke actually travels very easily through areas of flooring (or ceiling), through ventilation, or even through plumbing! I live in such a dwelling, with my 2 1/2 year old son and his lovely mother. And the tenant that rents the residence below us, refuses to smoke outside, even when the weather is clearly warm enough to do so comfortably. The second and third-hand comes up into our apartment through various sections in our fairly old 3-story apartment building - we live on the top floor - and at times it is so dense that we can actually see it in the air. Clearly in those circumstances, we open the front and back doors to our balconies, and use a fan to properly ventilate the apartment. Actually, we need to use 3 fans, since the apartment is rather long and old fashioned, and there are no other sources of ventilation aside from the front and back balcony doors. However, we cannot leave our doors open all day and all night, since it would basically be equivalent to inviting people to steal from us, and we would freeze to death in the winter. Not to mention, that it probably has a measurable effect on our heating & electricity bill. So when we come home, we often find that the apartment smells awful. To be specific, it smells like a mixture of cigarette smoke and fabreeze, which our neighbor downstairs thoughfully uses to mask the odor. Thanks for the thought, but the fabreeze really doesn't make it smell any better, and it certainly isn't reducing the health risks to my son.

I find it particularly bothersome when I hear my son cough in the middle of the night and I go into the kitchen to get him a glass of water, only to be greeted by a cloud of carcinogens. It's really no wonder why he's coughing. 

It's most certainly not healthy for our son, or us, at any time of the day or night. I've asked our neighbor politely to only smoke on the balcony, making specific mention about my concern for my son, and I've even asked the landlord to speak with our neighbor, but this hasn't made a difference and has only made our neighborly relationship less pleasant. Actually, our landlord lives in the building too, and he shares the exact same cloud of carcinogens coming up through the flooring. He also said it's intolerable at times, but unless there's a law about it, there's really not much more he can do. Moving is not an option. We really like our place, and from the landlord's perspective, he's stuck - this building is his property, business, and home. We live near a great park and we get a great sunset on our balcony. The kids in the neighborhood all seem happy, it's minutes from downtown and just far enough to be not down-towny, and ... well, there's a really great park across the street!

When will smoking laws catch up with common sense!?

I think this is a reasonable suggestion to the committee responsible for making smoking laws. Although the residences in question are not public buildings, there are direct effects on the health and safety of members of the public. It's basically the same logic that requires drivers to drive slowly in an area where a deaf child lives, even if it's not their child. Logical, right? Complaints would probably be followed by a building inspection and a mandatory no-smoking sign. I'm just hoping that maybe someone in the Ontario & Quebec governments will read this post and decide to finally take some action so that smoking laws catch up with common sense.

Will NVidia Follow Suit of AMD's Doc Disclosure?

Recently, AMD committed to releasing technical documents for their GPUs in order to assist open-source software developers to write better 2D and 3D graphics drivers. AMD actually followed through with that committment as well, and you can find the technical documentation here, if you're interested. Thanks AMD!

Although AMD will continue to release binary-x86* Linux drivers, the release of their chipset documentation (actually for R300 R500 and R600 series), is intended to improve the 'out-of-the-box' experience for PC users.

AMDs chips are entirely x86, from what I can tell, although I think i remember a rumor that they licensed some of their graphics technology to Apple for the chips that went into the iPhone, iPad, and iPod Touch. Aside from that AMD has no (publicly visible) vested interest in having graphics drivers that are architecture independent.

On the other hand, NVidia actually purchased an ARM License and produces their own Cortex-A8 and Cortex-A9 silicon with integrated NVidia graphics (Tegra, Tegra2), so they have both an x86 and an ARM presence now. Not only that, but NVidia continues to be the sole surviving GPU company, since AMD bought out ATI.

However, NVidia seems to be encountering production delays trying to get (Linux-based?) Tegra2 products to market. I can only assume that they aren't having silicon issues[1], so it really must be an issue getting the hardware to work well. They have opened up their Tegra2 site to Linux developers, offering a development board, source code, and binaries. However, I'm really left wondering if they could also benefit from disclosing some documentation of their graphics cores and perhaps the Tegra2 TRM, so that the next generation of NVidia-powered mobile devices would also provide an excellent 'out-of-the-box' 2D and 3D user experience.

Will NVidia follow suit with NDA-free documentation disclosure? Lets hope so... it would definitely be enough convincing to get me to buy a Tegra2-based device.

[1] as in: whoops! this graphics subsystem only processes data at 1/2 the necessary rate! .... ahem... maybe you know who I'm talking about

20100613

Linux on the Nokia N8?

Incidentally, if there is anyone interested in hacking Linux (read Android, Angstrom, Gentoo, etc) onto the Nokia N8, please leave a comment below. Honestly, this is probably the best hardware I've yet seen (lacking noise-cancellation) for a potential hacker-friendly device. I am making the assumption now that Nokia used an OMAP3 with this device, which is probably the best SOC (in terms of Linux-hacker-friendliness) to date with freely available documentation.

Pre-Departure Updates

That last few weeks have been insanely busy for me.

First, I sold all of my furniture and said goodbye to my former apartment in Kiel, since I'll be leaving for Montreal on Tuesday (yaaay!!). Since then, I've been couch-surfing at a friend's apartment down the street. Moving out was a huge undertaking, and I'm quite relieved that its over. There's something extremely liberating in a sort of Zen-Buddhist way about living out of a backpack.

Also, I've been putting in crazy amounts of overtime on my thesis project, which is coming along spectacularly. I've been meaning to write a blog post about it, without giving away too many things prematurely (call me superstitious, but I feel it could jinx me in the end). All I can really say at the moment, is that it's really pushing the physical limits, and that the antenna actually depends on materials being in the near-field. I will allow myself to expand on this point alone for clarification. For most people with any background in physics or engineering, it's common knowledge that EM wave propagation slows down in matter. The wave propagation velocity is equal to the speed of light in free space, but in any material with a relative permittivity greater than 1, the propagation velocity decreases. However, since the measure of time remains constant, the frequency remains constant. Subsequently, in order to maintain equality, the wavelength (L) shrinks according to the equation L = cr / f. A really fantastic consequence of this (antennas not-in-free-space), is that an antenna tuned to a specific frequency surrounded by a given material is often a significant fraction smaller than the equivalent antenna in free space. The resonance remains the same regardless of the angle of incidence (although directional gain is clearly affected). Half-space (or really multi-space) simulations of my antenna design (thus far) have allowed me to reduce the antenna size by a factor greater than 2! Without this near-field effect, it would literally be impossible to create an antenna that resonated in my required frequency range (the lower frequency bound being inversely proportional to the antenna dimensions - the limiting factor). This last week, I've been working on accurate 3D modelling of a planar antenna projected onto the surface of a half-ellipsoid (in order to approximate the inner curvature of a prosthetic eye), which will be the final addition to my simulation. I will then need to do some fine-tuning of the antenna dimensions (this will likely be some sort of constrained numerical optimization, perhaps MMSE), and finally I'll be able to build a physical prototype. Its safe to say though, that it has been far from an easy task. Limitations of our FDTD software and API did pose a major hurdle at one point. I've been doing a lot of the 3D modelling lately in Matlab (with its severely limited Dulauney triangulation capabilities) but I will eventually (or rather in the next week or two) have to write a Dulauney triangulation module in pure Python to interface with the FDTD API. I'm not a huge fan of Python, but I do what I must. In short, I really think that this antenna will be the first of its kind. I can't imagine that anyone has ever created such a specific design, just as the Eyeborg project is equally the first of its kind. The remaining things will be a bit of an exercise in reverse engineering, since I received absolutely zero assistance (so far) from WUSB transceiver chip vendors. I'll also need to improve the state of the Linux WUSB stack. Hopefully when chip vendors see a demonstrated prototype they'll be more inclined to cooperate with us on the Eyeborg design.

My GSOC project was on a bit of a hold this week, since it was my last week in Germany and I needed to focus on thesis work before my flight on the 15th. However, tonight I should be able to accomplish the tasks that I set for myself last monday. Keep an eye on my GSOC blog tomorrow for my weekly report.

Lastly, I leave you with a token of motivational music that should indicate my my overly-caffeinated state of late. Major thanks go to the countries of Ethiopia (for producing such great coffee), and Austria (for inventing RedBull).

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.