Pluto Schmuto!

Ok, so the IAU decided not to call Pluto a planet. Big Deal! It is what it is, and it's still there!

Seriously, just because the astronomers decided to appropriate the formerly non-scientific word 'planet', doesn't mean everyone has to rush out and buy new solar system posters that stop at Neptune! Let the IAU redefine 'planet' if they want to. It shouldn't matter to you unless you're trying to get published in Nature or something.

I think I agree with downgrading Pluto. The director of the Hayden Planetarium said something like "if you put Pluto where the earth is, it would grow a tail, and that's no way for a planet to behave." I agree - that's more like a comet than a planet.

In fact, here's an idea! I suggest that we remove digit status from the number 9. Not only would gas stations be forced to remove all those annoying 0.9 cents from their prices, there wouldn't be any more debate about Pluto no longer being the "9th" planet - whatever that means.

I'm Just Asking

If you don't like subatomic particles, this post probably isn't for you. If you do, then you will quickly discern that I really don't know what I'm talking about!

So, I'm just asking -

(1)
Since a neutron decays into a proton and an electron, can a neutron capture a positron and become a proton? Seems like the positron would anihilate the neutron's 'inner electron-ness', leaving a protron where the neutron was.

(2)
Then, if that can happen, could an anti-neutron absorb an ordinary electron to become an anti-proton?

(3)
Now, what happens if an anti-neutron collides with an ordinary proton? They're not anti-particles, so it doesn't seem like they'd anihilate one another. If protons and anti-neutrons don't destroy one another, could they be made to stick together? As though they were a deuterium nucleus, but with an anti-matter neutron?

(4)
Would this thing be stable? And what would you call it? Would you be able to put electrons in orbit and have something chemically identical to regular deuterium?

(5)
And finally, if you could have this proton/anti-neutron form of deuterium, and the answer to (2) is 'yes', what would happen if you blasted a sample of this stuff with an electron beam? Could the anti-neutrons in the weird deuterium capture electrons, and change into anti-protons while in this weird nucleus? If so, it's pretty apparent what ought to happen when the newly formed anti-proton notices it's bound to a regular proton.

So, if the answers to those questions are mostly 'yes', it would seem that you'd have a scenario where you could keep a supply of this relatively harmless stuff just like regular hydrogen, and then when you want some quick energy, hit it with an electron beam and induce something akin to total conversion of mass to energy.

Granted, you probably wouldn't get back nearly as much energy as you'd have to put in to (A) create anti-neutrons, however one goes about that, and to (B) get the anti-neutrons absorbed into a supply of regular hydrogen. This certainly is not a primary energy source, and highly probably not even an efficient means of storing energy, either, but there might be niche applications where the total conversion would invaluable - like trying to move spacecraft on the scale of light years per decade.

Doing Low-Res Graphics in Windows

Chances are you are reading this post on a screen that's running in excess of 1280 x 1024 resolution, and you are wondering "why would I want low resolution graphics?"

What do I mean by 'low resolution' graphics? Generally, anything less than the full screen resolution, where one lo-res 'pixel' maps to an N x N patch of real screen pixels. I'm not talking about throwing the graphics adapter into a low-resolution mode, but simply using some (or all) of the windows screen to display low resolution images, leaving the graphics adapter settings alone. For example, suppose you want a display that's 160 x 160 pixels. You might make each lo-res pixel map to a 4 x 4 chunk of your 1280 x 1024 display. Then you create your low-res images as though you had a 160 x 160 screen, but that 'screen' is just a 640 x 640 patch of your (unchanged!) 1280 x 1024 display. In some cases you might even want to take over the whole display, so called 'full screen' mode, for the production of low res images.

Why do I want low res graphics? Well, sometimes you might have a program whose output is inherently low resolution. For example, maybe you have a simple neural net arranged as a 16 x 16 grid of nodes, and you want to see the overall network activity as a color map. If you use single pixels on your 1280 x 1024, your network color map will be a tiny patch about half the size of the standard desktop icon! Or, suppose you want to emulate an old computer that had say, 128 x 48 resolution - again, you need to map the low res pixels to something larger so you can simply see it.

HOW can you get efficient low res graphics? Suppose you want to map 80 x 64 images onto a 640 x 512 chunk of real estate. Each of your low-res pixels will be an 8 x 8 chunk of real pixels. You could try writing your own routine to do 64 separate calls to SetPixel, but this will run like absolute molasses. Slightly better, you can create an off-screen device context with the 80 x 64 bitmap on it, and call StretchBlt to do the heavy lifting, but this is still pretty slow.

There are any number of better ways. Probably one of the better ones is to use Open GL, map a quad to your display area, and put a low-res texture map onto this quad; then operate on the texture map's 80 x 64 pixels, and let the Open GL renderer handle creating the 8 x 8 patches. Unfortunately, using Open GL like this incurs a bunch of calls to get GL set up, and a bunch more GL calls per low-res pixel, and though it's pretty fast, it tends to be finicky code.

But here's the cool and surprising thing I discovered today. Just make sure opengl32.lib gets linked into your Win API code. Somehow, when the .exe includes opengl32.lib (and maybe glu32.lib), StretchBlt goes into warp speed. You may need to put a dummy call to a GL function in your code to cause the linker to import the gl libs, but your code doesn't need to call any GL functions at runtime, to realize GL-like performance. Apparently, when Windows loads your .exe, and imports GL, the GL lib somehow overrides the implementation of StretchBlt. The up-side to this is that you can just use single calls to lowly SetPixel (against your off screen, low res bitmap) and then when you're ready to update the on-screen view, call StretchBlt. I have seen each pixel of a 40 x 32 offscreen map touched with SetPixel, then blitted to a full 1280 x 1024 display at 100Hz using no more than about 20% CPU utilization.

I realize this is a bit hack, but in terms of performance vs simplicity of code, it's worth looking at.