Two weeks ago, I posted two SAT-style Quantitative Comparison questions. This week, I am posting the solutions (sorry, I know it's a bit late).
If we let the radius of the inner circle be r and the length of segment BC be s such that the radius of the outer circle is r+s, then we can express all the quantities that we are interested in in terms of r and s.
The length of arc CE is:
¼(2π(r+s)) = ½πr + ½πs
The length of arc BD plus the length of segment DE is:
¼(2πr) + s = ½πr + s
The length of segment CB plus arc BD plus the length of segment DE is:
s +¼(2πr) + s = ½πr + 2s
When comparing each pair of terms, the ½πr cancel each other out. Because s is a length, we know that s>0, which means that ½πs is always greater than s, but is always less than 2s. In terms of answering the quantitative comparison questions, this means the answer to the first question must be A and the answer to the second question must be B.
Put another way, if you are walking around a 90 degree arc (such as from point C to point E), it will always be faster to walk around the outer arc than to walk to an inner arc, traverse it, and return to the outer arc. What is particularly interesting is that this is true regardless of the radius of the inner arc.
Now before you start taking the outside edge of every curve, note that this only holds true for arcs less than a certain size. For example, what if it you were traversing a semicircle instead?
The length of the outer arc would be:
½(2π(r+s)) = πr+πs
The length of the two straightaways plus the inner arc would be:
s +½(2πr) + s = πr + 2s
Because πs is greater than 2s, it makes more sense to walk to the inner arc when walking around a semicircle! So where is the breaking point? This can be determined by letting x be the fraction of the circle to traverse and setting the two path lengths equal to one another and solving for x:
x(2π(r+s)) = x(2πr) + 2s
2πxr+2πxs = 2πxr + 2s
2πxs = 2s
πx = 1
x = 1 / π
Plugging that into Google Calculator, we see that x is ~0.318, so once you're walking more than a third of the way around a circle, it makes more sense to move to the inner arc.
I thought that this would make a great SAT question for several reasons. First, and most importantly, this is a quantitative comparison question that does not have any numbers, yet its answer is not D! I'm pretty sure that most students hated geometry (so sad!), so when they come to something like this, it's pretty easy to throw up one's hands and declare the question unsolvable. Of course such a student would be incorrect...
Also, this question is resistant to some common SAT-solving techniques. For example, for geometry questions where the figure is to scale (such as this one), The Princeton Review will tell you to make small marks on your answer sheet so you can use it as a ruler, but because this problem involves arcs, that is of little help. Another common SAT tip is to redraw the diagram, exaggerating r or s, but if you play around with that, you can probably convince yourself that there are cases where one quantity is larger than the other, but it's hard to say conclusively that it holds true for arbitrary values of r and s.
That means the only ones who will be answering the question correctly are those who can do the math. Isn't that how it should be?
Sunday, April 5, 2009
Tuesday, March 24, 2009
It's time to add baseball schedules to Google Calendar!
It's not very flashy, but I created a Google Calendar for each MLB team's 2009 schedule:
http://mlb.bolinfest.com/
Each calendar will be updated automatically – I have a script that runs twice an hour while baseball games are on (it gets a break from 3am-noon eastern time) to scrape the latest data and update all of the calendars. Unfortunately, I don't think the calendars will be re-indexed that quickly by Google Calendar, but it's better than nothing.
I actually wrote Chickenfoot code two years ago to scrape data from mlb.com for use with CalMap and wikicalendars.com. Unfortunately, I never quite got Chickenfoot working with cron (which meant I manually ran the Chickenfoot script every morning to update the calendars), so this year I actually decided to run my original JavaScript code using Rhino since it's easy to kick off a Java process using cron. It sounds a little crazy, but it works great!
http://mlb.bolinfest.com/
Each calendar will be updated automatically – I have a script that runs twice an hour while baseball games are on (it gets a break from 3am-noon eastern time) to scrape the latest data and update all of the calendars. Unfortunately, I don't think the calendars will be re-indexed that quickly by Google Calendar, but it's better than nothing.
I actually wrote Chickenfoot code two years ago to scrape data from mlb.com for use with CalMap and wikicalendars.com. Unfortunately, I never quite got Chickenfoot working with cron (which meant I manually ran the Chickenfoot script every morning to update the calendars), so this year I actually decided to run my original JavaScript code using Rhino since it's easy to kick off a Java process using cron. It sounds a little crazy, but it works great!
Monday, March 23, 2009
Web Content Wizard is fixed!
My Web Content Wizard is fixed! Something must have changed on Google's side – I have not touched the code for the Wizard in years, but users have been writing in for some time now asking me to fix it.
I remember that setting up AuthSub the first time around was pretty miserable, so I was reluctant to sit down and try to debug it. I'm not sure what went wrong, but visiting https://www.google.com/accounts/ManageDomains to register bolinfest.com appeared to fix the problem.
I remember that setting up AuthSub the first time around was pretty miserable, so I was reluctant to sit down and try to debug it. I'm not sure what went wrong, but visiting https://www.google.com/accounts/ManageDomains to register bolinfest.com appeared to fix the problem.
Sunday, March 22, 2009
Do you remember SAT math?
The SAT I math test has a special class of questions called Quantitative Comparisons. Each question shows two columns, A and B, each describing some quantity, but the same four choices are always the same:
A. The quantity in Column A is greater.
B. The quantity in Column B is greater.
C. The two quantities are equal.
D. The relationship cannot be determined from the information given.
These questions can be devilishly tricky (particularly when the answer is D). Consider this classic example:
x > 0
Many students will only consider integer values of x and choose B as their answer, which is incorrect. What if x is ¼? Then the value of Column A is ½ and the value of Column B is ¼, so Column A is greater! But if x is any value larger than ½, then Column B will be greater. This means the correct answer must be D. (I deliberately chose 2x instead of x to eliminate the case where trying x=1 makes the two columns equal and trying any x>1 makes Column B greater, which makes it easier to come up with D as the right answer.)
So that is a quantitative comparison question. Like many upper-middle-class kids from the northeast, I took the SATs for the first time in the 7th grade to try to get into CTY. I didn't know what CTY was at the time, but my mother did, and fortunately for me, she recognized what a tremendous opportunity it would be for me to go. Mom bought me my first copies of 10 SATs and Cracking the SAT that year. (I say "first copies" because I had to buy new ones the following year when they re-centered the scoring and changed the test.) The SAT became my new challenge, and I've been kinda obsessed with the thing ever since.
Which is why while pondering the most efficient route on my walk to work, which involves walking around an arc (a rarity in New York City), I have developed the following Quantitative Comparison question:

And also the following quantitative comparison question for the same diagram:
I'll write a follow-up post with the answers in a couple of days. I know I found the result surprising (and now I know the best way to walk to work)!
A. The quantity in Column A is greater.
B. The quantity in Column B is greater.
C. The two quantities are equal.
D. The relationship cannot be determined from the information given.
These questions can be devilishly tricky (particularly when the answer is D). Consider this classic example:
x > 0
| Column A | Column B |
|---|---|
| 2x | (2x)2 |
Many students will only consider integer values of x and choose B as their answer, which is incorrect. What if x is ¼? Then the value of Column A is ½ and the value of Column B is ¼, so Column A is greater! But if x is any value larger than ½, then Column B will be greater. This means the correct answer must be D. (I deliberately chose 2x instead of x to eliminate the case where trying x=1 makes the two columns equal and trying any x>1 makes Column B greater, which makes it easier to come up with D as the right answer.)
So that is a quantitative comparison question. Like many upper-middle-class kids from the northeast, I took the SATs for the first time in the 7th grade to try to get into CTY. I didn't know what CTY was at the time, but my mother did, and fortunately for me, she recognized what a tremendous opportunity it would be for me to go. Mom bought me my first copies of 10 SATs and Cracking the SAT that year. (I say "first copies" because I had to buy new ones the following year when they re-centered the scoring and changed the test.) The SAT became my new challenge, and I've been kinda obsessed with the thing ever since.
Which is why while pondering the most efficient route on my walk to work, which involves walking around an arc (a rarity in New York City), I have developed the following Quantitative Comparison question:

CE and BD are 90° arcs on circles which are concentric at point A. Segment AC is greater than segment AB.
| Column A | Column B |
|---|---|
| The length of arc CE. | The length of arc BD plus the length of segment DE. |
And also the following quantitative comparison question for the same diagram:
| Column A | Column B |
|---|---|
| The length of arc CE. | The length of segment CB plus length of arc BD plus the length of segment DE. |
I'll write a follow-up post with the answers in a couple of days. I know I found the result surprising (and now I know the best way to walk to work)!
Tuesday, March 3, 2009
Tips for Tasks
If you saw my recent post on the Gmail blog, you've probably figured out that I work on Tasks. I've put together a personal list of tips to help you get the most out of Tasks:
P.S. If you have that problem where the popup with the arrow pointing to Tasks appears every time you log into Gmail: (1) I apologize, and (2) if you click on the Tasks link that it is pointing to, the popup should never show up again. Tell your friends!
- Checking Tasks from your phone
- Printing a task list
- Viewing multiple lists at once
- Getting a bigger view of Tasks
- Assigning priorities to tasks
- Moving Tasks between lists
- Adding any type of conversation to Tasks
- Accessing Tasks when Gmail is unavailable
P.S. If you have that problem where the popup with the arrow pointing to Tasks appears every time you log into Gmail: (1) I apologize, and (2) if you click on the Tasks link that it is pointing to, the popup should never show up again. Tell your friends!
Monday, February 9, 2009
A problem only I would have (or "How to build the most overengineered lightswitch possible")
Tonight I decided I should blow the dust off the machine I got from Dell a couple of years ago so I could achieve my longstanding dream to have a giant programmable lightswitch. I've lived in at least six apartments over the past two years (protip: keep track of old addresses by checking where you've shipped stuff on Amazon), so I've never been in any place long enough where it was worth trying to set this up. With my 13-month lease in hand, it seemed like it was finally time to try this out.
The key elements that I've acquired along the way are a Dell touchscreen monitor (2005), Windows XP machine (2007), and the X10 ActiveHome Pro 9 Piece Kit (2004?). My plan for stringing these things together seemed pretty simple:
Simple, right? Actually, it had far fewer snafus than some of my other projects. Step one was to get the touchscreen working even though I didn't have the CD with the drivers. Despite my repeated Googling, the drivers were pretty hard to find until I discovered that somehow I was being sent to Dell Australia instead of Dell US (work VPN playing games, maybe?), but once I got that straightened out, I got the monitor live and responding to touch pretty easily.
The next step was to get the ActiveHome software running. Fortunately, I backed up the installer for the SDK on bolinfest.com a few years ago because I figured I would lose it otherwise (I was right!). Installing the SDK was no problem, but I couldn't seem to find the thing that launches the ActiveHome GUI pictured on the web site. This wasn't a big deal because the SDK comes with sample code in a bunch of languages, including JScript, which you can just load in IE if you allow ActiveX to do its thing. I even got the JScript sample to stop giving me ActiveX warnings every time I loaded it by sharing the folder and adding it as a Trusted Site. (The Trusted sites thing in IE doesn't let you trust local files unless you serve them from as a shared folder -- I'm wary of what I've opened myself up to as a result of this.)
Now I was up to step three: "press the big red button." I pressed. I pressed again. I pressed several more times and exclaimed some things I do not care to repeat. My X10 components had been working fine via the remote from the Kit until a few weeks ago when I bought some new components (uh-oh) and tripped a circuit breaker while trying to install a Socket Rocket in my apartment. I was hoping that maybe the x10 modules would respond better to the software than to the remote (what the hell do I know?), but obviously they did not, so I checked out one of the x10 troubleshooting pages. It said something about opposite-phases-blah-blah-don't-you-know-I-got-Cs-in-my-EE-courses-because-I-couldn't-be-bothered-to-go...
I really had no idea what I was reading, but I made up this hypothesis that tripping the breaker had knocked things out of phase and that turning it off and on again would magically realign my outlets. Believe it or not, this actually seemed to work! That was, until I realized that once I plugged anything else into the outlet next to the one that had the x10 module plugged into it, the x10 module would stop working. This is a problem since I don't have too many options when it comes to outlets in my apartment, so I'm not sure how I'm going to resolve this. Currently, I have to choose between the possibility of controlling a lamp via my iPhone and plugging my laptop into the wall. It's a toss-up.
Since I've come this far, I'm strongly considering reworking the outlet situation in my apartment to accomodate my fetish for automated lights. If any of you circuit jerks out there can tell me how to do this without making a trip to the electrical section at Home Depot, I'd be much obliged. I only have 10 months until it's time to setup the AIM bot to control my Christmas lights again!*
*I actually did that in 2005 using the SDK and an existing AIM bot library written in C#. I went with the AIM bot because it seemed a lot simpler than running IIS. It was also more fun, though I guess nowadays I'd do it over Jabber instead. When was the last time I logged on to AIM?
The key elements that I've acquired along the way are a Dell touchscreen monitor (2005), Windows XP machine (2007), and the X10 ActiveHome Pro 9 Piece Kit (2004?). My plan for stringing these things together seemed pretty simple:
- Plug monitor into computer
- Install ActiveHome software
- Press giant virtual button
Simple, right? Actually, it had far fewer snafus than some of my other projects. Step one was to get the touchscreen working even though I didn't have the CD with the drivers. Despite my repeated Googling, the drivers were pretty hard to find until I discovered that somehow I was being sent to Dell Australia instead of Dell US (work VPN playing games, maybe?), but once I got that straightened out, I got the monitor live and responding to touch pretty easily.
The next step was to get the ActiveHome software running. Fortunately, I backed up the installer for the SDK on bolinfest.com a few years ago because I figured I would lose it otherwise (I was right!). Installing the SDK was no problem, but I couldn't seem to find the thing that launches the ActiveHome GUI pictured on the web site. This wasn't a big deal because the SDK comes with sample code in a bunch of languages, including JScript, which you can just load in IE if you allow ActiveX to do its thing. I even got the JScript sample to stop giving me ActiveX warnings every time I loaded it by sharing the folder and adding it as a Trusted Site. (The Trusted sites thing in IE doesn't let you trust local files unless you serve them from as a shared folder -- I'm wary of what I've opened myself up to as a result of this.)
Now I was up to step three: "press the big red button." I pressed. I pressed again. I pressed several more times and exclaimed some things I do not care to repeat. My X10 components had been working fine via the remote from the Kit until a few weeks ago when I bought some new components (uh-oh) and tripped a circuit breaker while trying to install a Socket Rocket in my apartment. I was hoping that maybe the x10 modules would respond better to the software than to the remote (what the hell do I know?), but obviously they did not, so I checked out one of the x10 troubleshooting pages. It said something about opposite-phases-blah-blah-don't-you-know-I-got-Cs-in-my-EE-courses-because-I-couldn't-be-bothered-to-go...
I really had no idea what I was reading, but I made up this hypothesis that tripping the breaker had knocked things out of phase and that turning it off and on again would magically realign my outlets. Believe it or not, this actually seemed to work! That was, until I realized that once I plugged anything else into the outlet next to the one that had the x10 module plugged into it, the x10 module would stop working. This is a problem since I don't have too many options when it comes to outlets in my apartment, so I'm not sure how I'm going to resolve this. Currently, I have to choose between the possibility of controlling a lamp via my iPhone and plugging my laptop into the wall. It's a toss-up.
Since I've come this far, I'm strongly considering reworking the outlet situation in my apartment to accomodate my fetish for automated lights. If any of you circuit jerks out there can tell me how to do this without making a trip to the electrical section at Home Depot, I'd be much obliged. I only have 10 months until it's time to setup the AIM bot to control my Christmas lights again!*
*I actually did that in 2005 using the SDK and an existing AIM bot library written in C#. I went with the AIM bot because it seemed a lot simpler than running IIS. It was also more fun, though I guess nowadays I'd do it over Jabber instead. When was the last time I logged on to AIM?
Sunday, January 18, 2009
Using an IFRAME to force a doctype
There have been times when I wanted to create a JavaScript widget that I could embed into any web page. One problem I ran into was that I would develop my widget in a standards mode page, but then it would not work when embedded on a page in quirksmode.
"Who still uses quirksmode?" you might ask. Well, for legacy reasons, iGoogle gadgets do. I thought that OpenSocial fixed that, but item 6 of the spec says otherwise, though the discussion group suggests a distasteful workaround.
Either way, this whole doctype thing is a problem. On a web page, the
One option that does work is to have an empty html page with the strict doctype on the same domain as your JavaScript widget. That way, your widget can write its content into a local iframe using the empty html page as its source. The drawbacks to that approach are: (1) it complicates the API of your widget because it requires the consumer of your API to make a server-side change and bake the URL into calls to your API; and (2) you have to add some extra logic to listen for the iframe to load before you can write to it, so it forces your API to become asynchronous rather than synchronous.
The best solution I've seen so far is to dynamically create an iframe with no
One thing that is particularly advantageous with this technique is that if your widget requires its own stylesheet, it can load it in the iframe instead of the top-level page where your CSS class names run the risk of conflicting with the CSS class names used in the host page. So even if you know that your widget is going to be used in a standards-compliant page, you may want to use this technique to create a "fresh namespace" for your CSS.
The only disadvantage that I've found with iframeing over inlining is with managing overlays that need to appear outside the iframe. In the test page, there is a green box that appears over the iframes and the main page. For it to be visible, it needs to be an element of the top-level page, which (1) may be in quirksmode and (2) will not honor the CSS rules defined in your iframe. That means that you may have to design your popup so that it works in both rendering modes and uses inline styles (exactly what we were trying to avoid with our universally-embeddable JavaScript widget!).
Also, the JavaScript code that manages such an overlay needs to be wary of its use of the
Overall, I am still pretty happy with this solution, though one thing that occurred to me is that this is a little frightening with respect to phishing in that a malicious web page could easily display an iframe to foreign content (that is familiar to you) and then display its own login box or credit card form on top of it to lure you to enter your information. I mentioned this to Mihai, and he said this is somewhat of a known issue, citing this example at zombieurl.com (warning: page contains sound). I guess that goes to show that you can never be safe from zombies, not even on the Internet.
"Who still uses quirksmode?" you might ask. Well, for legacy reasons, iGoogle gadgets do. I thought that OpenSocial fixed that, but item 6 of the spec says otherwise, though the discussion group suggests a distasteful workaround.
Either way, this whole doctype thing is a problem. On a web page, the
document has a doctype property, but it's read-only, so trying to edit that is a dead-end. Originally, I tried manipulating the content of an iframe with src="about:blank" which I thought would be clean because it had no content, but no content means no doctype, so it is also stuck in quirksmode.One option that does work is to have an empty html page with the strict doctype on the same domain as your JavaScript widget. That way, your widget can write its content into a local iframe using the empty html page as its source. The drawbacks to that approach are: (1) it complicates the API of your widget because it requires the consumer of your API to make a server-side change and bake the URL into calls to your API; and (2) you have to add some extra logic to listen for the iframe to load before you can write to it, so it forces your API to become asynchronous rather than synchronous.
The best solution I've seen so far is to dynamically create an iframe with no
src attribute and to use document.write() to insert the content of the iframe or to set the src attribute to javascript:parent.functionThatReturnsTheDesiredContentAsHtml(). This test page demonstrates both techniques.One thing that is particularly advantageous with this technique is that if your widget requires its own stylesheet, it can load it in the iframe instead of the top-level page where your CSS class names run the risk of conflicting with the CSS class names used in the host page. So even if you know that your widget is going to be used in a standards-compliant page, you may want to use this technique to create a "fresh namespace" for your CSS.
The only disadvantage that I've found with iframeing over inlining is with managing overlays that need to appear outside the iframe. In the test page, there is a green box that appears over the iframes and the main page. For it to be visible, it needs to be an element of the top-level page, which (1) may be in quirksmode and (2) will not honor the CSS rules defined in your iframe. That means that you may have to design your popup so that it works in both rendering modes and uses inline styles (exactly what we were trying to avoid with our universally-embeddable JavaScript widget!).
Also, the JavaScript code that manages such an overlay needs to be wary of its use of the
document variable as it is important to use it in the correct context (iframe vs. host page). It is best to create different getters for the two documents and to use those exclusively, avoiding direct access to document altogether.Overall, I am still pretty happy with this solution, though one thing that occurred to me is that this is a little frightening with respect to phishing in that a malicious web page could easily display an iframe to foreign content (that is familiar to you) and then display its own login box or credit card form on top of it to lure you to enter your information. I mentioned this to Mihai, and he said this is somewhat of a known issue, citing this example at zombieurl.com (warning: page contains sound). I guess that goes to show that you can never be safe from zombies, not even on the Internet.
Subscribe to:
Posts (Atom)