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
20100915
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).
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.
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.
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!
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.
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.
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:
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.
Subscribe to:
Posts (Atom)