The Black Hole in the Center of the Galaxy

So, there's been recent news of confirmation of the presence of a massive black hole in the center of the galaxy. This black hole has been accepted as a fact for a while now, but mostly as the mostly as the likely hypothesis that explains the movement of certain stars close to the center of the Milky Way. This study, on the other hand, has tracked the movement of a group of stars for 16 years, and has yield results that almost conclusively evidence the presence of this astral entity.

The interesting thing is that even after this study, the evidence is still indirect. I mean, we haven't seen the thing (although if it's there we know we can't see it). We've just been able to detect its presence by observing its effects. Isn't science amazing? It reminds me of my Electrical Workshop teacher in highschool. When we were learning the basic concepts, we started, of course, by learning what electricity is. And so, one of the things we learned is that you can't see electricity. He would ask "How do we know the damned thing is there then?", and then would tell us "We observe the effects it produces! Touch a live wire and you'll know there's electricity there!". So it's kind of the same thing here. Electricity lights a bulb, that's an effect, we know it's there. In this case, the black hole has an effect on the astral bodies in its vicinity, so we know it's there.

You have to love the scientific method!...

-- AI

Assertions and Errors

Out of any context, do those two words in the title of this post mean the same? I mean, is there any way in which those two things (assertions and errors) could be considered semantically equivalent? I would think not, but apparently many programmers think otherwise.

Java is a great programming language. It's a language that allows programmers to explicitly state error or "exceptional" conditions. Recently this language was extended with a feature that allows programmers to express intent explicitly: assertions. This is a great feature, because the assertions can be checked at runtime, so that the programmers assumptions are tested under operating conditions, aside from also serving as a form of documentation, making programming cleaner and more methodical.

As I just said, Java assertions are great, the problem comes when they are abused. Some programmers use them to "state errors", that is, to do the things that the exception and error mechanism of Java should do. Assertions should be used to express the conditions under which the program should operate, not error conditions! And so you find things in Java code like:

assert false;

which basically states an error state has been reached. I can't even start to explain why this is in so many ways wrong, but let us start with the obvious. What the heck does "assert false" mean? You are asserting 'false'. You are saying 'false' is 'true'. That doesn't mean anything! Whenever this line is reached, all you will be left with is a message saying the Universe will cease to exist tomorrow. It tells you nothing.

Now let's go with the practical problems. Since assertions are not meant to state errors, but just intent of normal operating conditions, their checking is optional. That is, to check them at runtime you have to enable assertion checking. This is something you do during production, but not on deployment. So basically, during actual operation, these assertions won't be checked. Which means that, if you use assertions as above, the errors won't be caught, and will just propagate through the system producing unpredictable, unstable system states. This just happened to me. I was using some code from someone with this bad habit, and I had not enabled assertions. So, the program ran 'fine' all the way through without apparent problem. Then, I enabled assertions to check some of my own assertions, and everything started breaking all over. A lot of 'assert false' assertions started popping, which means that the program wasn't actually running properly, and the results I was gathering before were probably incorrect. But before I enabled assertions, there was no sign of error conditions in the program!

If you are a programmer and reading this, please do not do this. If there is an error condition, then state it as an error, instead of asserting that 'false' is 'true', throw an error:

throw new Error("Error message");

see how easy that is? You will do yourself and those who use your code a big favor. Learn to understand the difference between errors and assertions!

Academic (Dis-)Honesty

A few days ago, I stumbled upon the following article. Apparently, the work of a group of researchers, related to stem cell research, was found to have many inconsistencies, enough to suspect academic dishonesty. Of course, an expert panel was assembled to conduct an investigation, and apparently the conclusion was that a PhD student in the team falsified data. The faculty involved in the research was absolved of any wrong-doing.

All parties deny any mischief and the student, in particular, attributes everything to an honest mistake. Personally, I don't buy it. In fact, I don't think it was only the student who was at fault. But I am no one to judge, and can't really know the ultimate truth. However, I have seen this happening. I have first-hand experience of people falling to the temptation of academic dishonesty, which is probably why I am skeptic of the innocence of those involved. This case seems to show the same signs as what I have seen before.

To anyone reading this that happen to work in a field of research: stay away from this. Don't fall into this trap. No matter how innocuous it may seem to be. Maybe you think it's just a little detail that you're fabricating, that doesn't really affect the overall result... just for aesthetic purposes... don't do it. Don't lie, because chances are you will be caught in your lie.

Also, you may think you are above this. "I would never even think of doing this, so there's no problem with me". Trust me, you will be tempted. You're working on that paper, the deadline is approaching... your performing experiments, cranking results. Everything is going great... crap! the machine broke! It's the last batch of experiments, but all the other repetitions were fine! You KNOW it's going to be OK... but don't have time to perform the last batch of tests before the deadline. But you KNOW what the results will be... what if you just say you did it and submit the paper. I mean, you're going to perform the experiment anyways, what's the harm? Don't do it.

While working in my field of research, I've the privilege to work with some of the most respected researchers in my field. One of them once told me: "The only thing you really have in this line of work is your reputation...". Sound advice. You don't want to put out there stuff that, later on, you might regret being associated with. Think about it next time you're about to report on the results of your latest research work.

Update: A friend of mine gave me this link to another report about the same incident with a slightly different take on the story.

Visit to SRI

Last week I had the chance to visit SRI International's Formal Methods Group. It was a very enriching couple of days. I got to meet some very smart people and to take a look at their work. It was a very inspiring experience.

We were able to take a look at their latest advances and present some of our own work (the work in my research group), so it was actually an ideas exchange meeting. Those folks work mostly on theorem prover technology (which is not exactly our work), however there were several ideas that seemed relevant to our work.

What I liked is that it was one of those meetings were you come back really energized and inspired from some of the cool things you see, but mostly from intereacting from other people that, like you, are producing science.

Also I could take a peek at the Silicon Valley itself: Palo Alto, Menlo Park, San José. This is where many big IT companies are headquartered, including the big Google :-) So it was an interesting trip overall.

First Entry

First entry... just created this blog to replace the old one, to which I had not posted in a long while. Also, to use the right screen name: Apolo Imagod. Let's see how it goes...