Introduction
Today is the day of the Scripps National Spelling Bee. I'll discuss the Bee near the end of this post, but first let's return to my main projects as we read from Stewart and Lemay.
Calculating the Cosmos Chapter 17: The Big Blow-Up
Chapter 17 of Ian Stewart's Calculating the Cosmos is called "The Big Blow-Up." As usual, each chapter begins with a quote:
"If I had been present at the creation, I would have given some useful hints for the better arrangement of the Universe."
-- Alfonso the Wise, king of Castile (attributed)
"A few years ago, the Big Bang theory of the origin of the universe fitted all of the important observations."
But this chapter is all about deficiencies with this theory -- the universe is just too "clumpy." In order to make the newer measurements work out, the titular "Big Blow-Up" or a "Bigger Bang" is needed. Its formal name is "inflation":
"At a critical juncture, very early in its existence, the nascent universe expanded to a huge size in an extraordinarily short time. Other deficiencies of the original Big Bang theory led cosmologists to bolt on two further assumptions: dark matter, a form of matter utterly different from normal matter, and dark energy, a form of energy that causes the expansion of the universe to speed up."
Stewart tells us that inflation and dark energy are the topics for this chapter. These are used to show why the universe is clumpier than expected:
"Cosmologists were also worried by a deeper issue, the horizon problem, which Charles Misner pointed out in the 1960s."
This isn't about why the universe is the shape it is, but why it is uniformly so -- that is, why parts of the universe billions of light years apart look the same. The expansion known as inflation gives a solution:
"Essentially, any localized bumps and dips that existed before inflation set in are suddenly spread out over a truly gigantic volume of spacetime."
But the question remains, what caused this inflation to happen in the first place? One proposal is that there's a hypothetical inflation-particle called an "inflaton," but there's a problem with it:
"The usual explanation of the structure of our universe assumes that the inflaton field switches on once, very early in the evolution of the universe, and then stays switched off."
There's another problem with our current standard explanations for where our universe came from, including how fast the universe is expanding:
"Cosmologists had expected it either to remain constant, leading to an 'open' universe that never stops growing, or to slow down as gravity hauls the expanding galaxies back together again to form a 'closed' universe."
Instead, the growth rate appears to be getting faster, based on High-z observations of redshift. Perhaps dark energy is the cause of this speeding -- to determine whether dark energy exists, it helps to consider a model of the universe that appears to be completely smooth:
"Cosmologists therefore compare the High-z observations with the predictions of this smoothed model. A delicate mathematical issue now surfaces, which seems to have been neglected until recently: is an exact solution of the smoothed-out model close to a smoothed solution of the exact model?"
The answer is that we think so, but we're not quite sure. It might be possible to explain the expansion of the universe without assuming that dark energy exists:
"In 2011, in a special issue on general relativity of a Royal Society journal, Robert Caldwell wrote: 'To date, it appears entirely reasonable that the [High-z] observations may be explained by new laws of gravitation.'"
There are, unfortunately, still some gaps in our knowledge about the origins of the universe -- for example, there appear to be some distant stars, red giants, that appear older than the universe itself:
"Perhaps the CMB [cosmic microwave background radiation] isn't a relic of the origin of the universe; just starlight that has bounced around the universe for aeons, being absorbed and radiated again."
Two Middle Eastern scientists -- Ahmed Ali (from Egypt) and Saurya Das (from India) -- have proposed alternatives to the Big Bang theory:
"Instead, Ali and Das employ Bohmian quantum mechanics, in which the trajectory of a particle makes sense and can be calculated."
Using these calculations, there was no singularity -- that is, no Big Bang -- and perhaps even no beginning of time. The author tells us that so far there's been no definite proof that there was a Big Bang with inflation, although from time to time claims of such evidence have been made, such as 2014:
"At the time the announcement was greeted with great excitement; either of those discoveries would be a shoo-in for a Nobel Prize."
But what was observed was space dust, not inflation -- a huge disappointment. Stewart concludes the chapter with a warning from Greek mythology:
"Hubris begets Nemesis, and Nemesis is hanging around a lot in the wings nowadays. The spirit of divine retribution may yet take center stage."
Lemay Lesson 17: Exceptions
Here is the link to today's lesson:
http://101.lv/learn/Java/ch17.htm
Lesson 17 of Laura Lemay's Teach Yourself Java in 21 Days! is called "Exceptions." And here's how the chapter begins:
Programmers in any language endeavor to write bug-free programs, programs that never crash, programs that can handle any situation with grace and that can recover from unusual situations without causing the user any undue stress. Good intentions aside, programs like this don't exist.
In real programs, errors occur, either because the programmer didn't anticipate every situation your code would get into (or didn't have the time to test the program enough), or because of situations out of the programmer's control-bad data from users, corrupt files that don't have the right data in them, network connections that don't connect, hardware devices that don't respond, sun spots, gremlins, whatever.
In Java, these sorts of strange events that may cause a program to fail are called exceptions.
OK, we have exceptions in C++ (and Logo) as well, so I'm already a little familiar. Exceptions are sort of like errors, but with exceptions we can program the computer to do something when the error occurs.
By the way, Lemay doesn't include any listings in this chapter. Instead, there are only code snippets which aren't runnable on their own:
Programming languages have long labored to solve the following common problem:
int status = callSomethingThatAlmostAlwaysWorks();
if (status == FUNNY_RETURN_VALUE) {
. . . // something unusual happened, handle it
switch(someGlobalErrorIndicator) {
. . . // handle more specific problems
}
} else {
. . . // all is well, go your merry way
}
What this bit of code is attempting to do is to run a method that should work, but might not for some unusual reason.
OK, I understand this so far.
At this point in the book, chances are you've run into at least one Java exception-perhaps you mistyped a method name or made a mistake in your code that caused a problem. And chances are that your program quit and spewed a bunch of mysterious errors to the screen. Those mysterious errors are exceptions. When your program quits, it's because an exception was "thrown." Exceptions can be thrown by the system or thrown by you, and they can be caught as well (catching an exception involves dealing with it so your program doesn't crash. You'll learn more about this later). "An exception was thrown" is the proper Java terminology for "an error happened."
Yes, I've definitely seen Java exceptions when running earlier programs.
The heart of the Java exception system is the exception itself. Exceptions in Java are actual objects, instances of classes that inherit from the class Throwable. When an exception is thrown, an instance of a Throwable class is created.
Yes, C++ is similar. I know it's seems silly -- an exception is an object, and like all objects, it can even have its own class data and methods.
So now that you know what an exception is, how do you deal with them in your own code? In many cases, the Java compiler enforces exception management when you try to use methods that use exceptions; you'll need to deal with those exceptions in your own code or it simply won't compile. In this section you'll learn about that consistency checking and how to use the try, catch, and finally language keywords to deal with exceptions that may or may not occur.
OK, this looks similar to what I already know as well.
The more you work with the Java class libraries, the more likely it is that you'll run into a compiler error (an exception!) similar to this one:
TestProg.java:32: Exception java.lang.InterruptedException must be caught or it must be declared in the throws clause of this method.
This basically means that if we have an exception, then we need to catch it. C++ is the same way.
Let's assume that you've been happily coding and during a test compile you ran into that exception message. According to the message, you have to either catch the error or declare that your method throws it. Let's deal with the first case: catching potential exceptions.
You've seen try and catch once before, when we dealt with threads. On Day 10, "Simple Animation and Threads," you learned about an applet that created a digital clock, and the animation paused once a second using this bit of code:
try { Thread.sleep(1000) }
catch (InterruptedException e) {}Of course, "Day 10" for us really means last year.
Suppose there is some action in your code that you absolutely must do, no matter what happens, whether an exception is thrown or not. Usually, this is to free some external resource after acquiring it, to close a file after opening it, or something similar. While you could put that action both inside a catch and outside it, that would be duplicating the same code in two different places. Instead, put one copy of that code inside a special optional part of the try...catch clause, called finally:
SomeFileClass f = new SomeFileClass();
if (f.open("/a/file/name/path")) {
try {
someReallyExceptionalMethod();
{ catch (IOException e) {
// deal with errors
} finally {
f.close();
}
}C++ doesn't have a finally keyword, but it does have default which is quite similar.
In the previous example you learned how to deal with methods that might possibly throw exceptions by protecting code and catching any exceptions that occur. The Java compiler will check to make sure you've somehow dealt with a method's exceptions-but how did it know which exceptions to tell you about in the first place?
To indicate that some code in the body of your method may throw an exception, simply add the throws keyword after the signature for the method (before the opening brace) with the name or names of the exception that your method throws:
public boolean myMethod (int x, int y) throws AnException {
...
}This is different from C++, where we don't have to declare this. But I can sort of see what's going on -- either the exception is caught within the same method (so we don't have to declare throws), or the method ends before it's caught (so we have to declare throws).
Once you decide to declare that your method might throw an exception, you have to decide which exceptions it might throw (and actually throw them or call a method that will throw them-you'll learn about throwing your own exceptions in the next section). In many instances, this will be apparent from the operation of the method itself. Perhaps you're creating and throwing your own exceptions, in which case you'll know exactly which exceptions to throw.
In addition to declaring methods that throw exceptions, there's one other instance in which your method definition may include a throws clause. In this case, you want to use a method that throws an exception, but you don't want to catch that exception or deal with it. In many cases, it might make more sense for the method that calls your method to deal with that exception rather than for you to deal with it. There's nothing wrong with this; it's a fairly common occurrence that you won't actually deal with an exception, but will pass it back to the method that calls yours. At any rate, it's a better idea to pass on exceptions to calling methods than to catch them and ignore them.
OK, I think I understand this.
If your method definition overrides a method in a superclass that includes a throws clause, there are special rules for how your overridden method deals with throws. Unlike with the other parts of the method signature, your new method does not have to have the same set of exceptions listed in the throws clause. Because there's a potential that your new method may deal better with exceptions, rather than just throwing them, your subclass's method can potentially throw fewer types of exceptions than its superclass's method definition, up to and including throwing no exceptions at all. That means that you can have the following two class definitions and things will work just fine:
public class Fruit {
public void ripen() throws RotException {
...
}
}
public class WaxFruit extends Fruit {
public void ripen() {
...
}
}Oh, I get it -- wax fruits don't rot, so they wouldn't need to throw the RotException.
There are two sides to every exception: the side that throws the exception and the side that catches it. An exception can be tossed around a number of times to a number of methods before it's caught, but eventually it'll be caught and dealt with.
Declaring that your method throws an exception is useful only to users of your method and to the Java compiler, which checks to make sure all your exceptions are being dealt with. But the declaration itself doesn't do anything to actually throw that exception should it occur; you have to do that yourself in the body of the method.
Lemay gives us a warning here about exceptions in C++ and Java:
You can only throw objects that are instances of subclasses of Throwable. This is different from C++'s exceptions, which allow you to throw objects of any type.
Exceptions are simply classes, just like any other classes in the Java hierarchy. Although there are a fair number of exceptions in the Java class library that you can use in your own methods, there is a strong possibility that you may want to create your own exceptions to handle different kinds of errors your programs might run into. Fortunately, creating new exceptions is easy.
In fact, C++ doesn't have a separate object called Throwable. In reality, C++ coders distinguish between which objects they intend to be thrown and which objects they don't.
What if you want to combine all the approaches shown so far? In your method, you'd like to handle incoming exceptions yourself, but also you'd like to pass the exception up to your caller. Simply using try and catch doesn't pass on the exception, and simply adding a throws clause doesn't give you a chance to deal with the exception. If you want to both manage the exception and pass it on to the caller, use all three mechanisms: the throws clause, the try statement, and by explicitly rethrowing the exception:
public void responsibleExceptionalMethod() throws MyFirstException {
MyFirstExceptionalClass aMFEC = new MyFirstExceptionalClass();
try {
aMFEC.anExceptionalMethod();
} catch (MyFirstException m) {
. . . // do something responsible
throw m; // re-throw the exception
}
}This is a bit tricky, since C++ coders rarely do this.
To finish up today's lesson, here's a quick summary and some advice on when to use exceptions…and when not to use them.
Because throwing, catching, and declaring exceptions are interrelated concepts and can be very confusing, here's a quick summary of when to do what.
If your method uses someone else's method, and that method has a throws clause, you can do one of three things:
- Deal with the exception using try and catch statements.
- Pass the exception up the calling chain by adding your own throws clause to your method definition.
- Do both of the above by catching the exception using catch and then explicitly rethrowing it using throw.
Lemay warns us that the we shouldn't get carried away with exceptions -- after all, they're called exceptions since they are intended to be used in exceptional cases.
Exceptions are cool. But they aren't that cool. There are several cases in which you should not use exceptions, even though they may seem appropriate at the time.
First, you should not use exceptions if the exception is something that you expect and a simple test to avoid that exceptional condition would make much more sense. For example, although you can rely on an ArrayIndexOutofBounds exception to tell you when you've gone past the end of the array, a simple test of the length of the array in your code to make sure you don't get that exception in the first place is a much better idea. Or if your users are going to enter data that you need to be a letter, testing to make sure that data is a letter is a much better idea than throwing an exception and dealing with it somewhere else.
When you first start using exceptions, it might be appealing to work around the compiler errors that result when you use a method that declared a throws clause. While it is legal to add an empty catch clause or to add a throws clause to your own method (and there are appropriate reasons for doing both of these things), intentionally dropping exceptions on the floor and subverting the checks the Java compiler does for you is very bad style.
Conclusion
Well, that was certainly an exciting finish to this year's spelling bee! As I mentioned in my Tau Day Eve post, one California girl had advanced to the finals in Orlando, and as usual, I root for the speller from my home state to win.
As it turns out, Chaitra, the sixth grader from California, is now officially a Texan. In fact, she and her family moved from Frisco (a nickname for San Francisco) to Frisco (a suburb of Dallas). Still, she's the closest I could get to having a Californian in the finals, and so I cheered for her to win anyway.
Chaitra advanced to the final two spellers. I notice that there was no "championship list" that starts when the field is reduced to the final three. Changes were made this year in order to avoid the "octochamp" situation that we had two years ago -- if it's almost 10:00 (Eastern) and there are still multiple spellers left, a 90-second lightning round begins where each remaining contestant spells as many words as possible in that time range. The one with the most words spelled right is the winner.
Sadly, Chaitra stumbled on "Neroli oil" -- named for the French spelling of an Italian region. Like many of the spellers before her, Chaitra had trouble with the unstressed schwa sound and chose the wrong vowel in the middle of the word. I often try to spell the words along with the contestants, especially if the word comes from French (the language I took as a young high school student) -- but this isn't a typical French word. The only part of the word I got right was the only part you got as well -- "oil." And since Chaitra is a sixth grader, I hope she makes it to the national bee again in the next two years -- I know she'll do great!
Lest I be accused of talking about the runner-up more than the winner, let me congratulate Zaila of Louisiana for becoming this year's champion. She was the only eighth grader who advanced past the first round, and she overcame her own schwa word -- "Nepeta" -- her final word was "Murraya," the name of a plant. She joked about the plant being named for comedian Bill Murray before spelling the final word.
Deep down, I was hoping Zaila would miss the word just so I could see the lightning round (and so that the former Californian Chaitra would still be alive). But who knows -- maybe there'll be a lightning round next year.
Now that the spelling bee is over, tonight will be my annual viewing of Akeelah and the Bee. But in a way, I already watched the real Akeelah tonight, because Zaila becomes the first black American ever to win the national spelling bee. (Recall that a black Jamaican girl won back in 1998.)
In one scene in the movie, Akeelah bounces a basketball to help her remember words. As it turns out, Zaila also enjoys basketball -- she even hopes to play in the WNBA some day. On the other hand, Zaila leapt in the air with excitement each time she spelled a word correctly. I don't recall Akeelah doing that in the movie -- I'll have to doublecheck that when I watch the movie again tonight
Also, Zaila says that she has been a competitive speller for only two years. Likewise, Akeelah has only competitively spelled for one year -- the span of the movie. (On the other hand, Chaitra won her first bee in kindergarten -- the same year that I won my first spelling bee trophy.)
And so that concludes this year's spelling bee. I look forward to next year's bee, and hope that things will be back to normal by then, with the gathering in Washington DC. On the other hand, I suspect that the word meaning round will be a regular feature of the bee, and the lightning round will be used to settle ties if too many spellers remained. I wish good luck to everyone who chooses to participate in next year's competition!
No comments:
Post a Comment