What advice would you give to a young woman in high school considering computer science?

Subject: Question: Young women in computer science

To: Keith Winstein <keithw@...>

Date: Fri, 26 Jul 2019 08:47:14 -0400

I am a senior at XYZ High School in Pennsylvania and the only young woman taking our AP computer science courses. My principal wants my thoughts on increasing computer science interest level among young women. I am asking a number of professors the following question:

What advice would you give to a young woman in high school considering computer science?

If you can spare a few minutes to respond via email, it would be greatly appreciated.  

Thank you.

---

Subject: Re: Question: Young women in computer science
From: Keith Winstein <keithw@...>
Date: Fri, 26 Jul 2019 12:53:10 -0700

I guess I would say "welcome"!! I hope you find computer science rewarding and look forward to reading your contributions to the field over time. There are so many diverse ways to be a computer scientist and to do computer science. I hope your early years in the field end up exposing you broadly and sparking your interest.

One thing I would say is that it's valuable to find good mentors, people you look up to and whose examples you can try to "live up" to and from whom you can learn as much as possible. A lot of undergraduates unfortunately become fixated on their own classmates, and worry about trying to "keep up" with these people or "catch up" to their level of preparation. In the grand scheme of things, these people are not so important -- in my experience, it's more valuable to have goals, and mentors and heroes who embody those goals and serve as an example for you to try to "live up" to over the many years of your (hopefully long) education and career. Of course it may take you a while to figure out what kind of person you want to become and who you want to look up to. :-)

I did a (brief) interview on my experience here: https://alum.mit.edu/slice/after-four-degrees-mit-alumnus-goes-wall-st-journal-stanford-faculty

And a different interview about graduate school here: https://cs.stanford.edu/~keithw/interview-2015-guo-wu-winstein.html

Some advice you may want to read: Justine Sherry's (https://people.eecs.berkeley.edu/~justine/advice.pdf) or Michael Ernst's (https://homes.cs.washington.edu/~mernst/advice/) or Jennifer Rexford's (https://www.cs.princeton.edu/~jrex/advice.html). The basic truth is that "imposter syndrome" is very common (among both men and women), and it can be helpful to recognize that.

The second thing I would say is that there are a lot of great events for women in computer science, and a lot of people I know really enjoy and are inspired by attending them! So, attend the Grace Hopper Celebration (https://ghc.anitab.org/), both while you're in high school and continuing in college, at least if you can make it and if it looks interesting to you. (This is probably the biggest one.) Consider attending an ACM-W event or starting an ACM-W chapter (https://women.acm.org/category/celebrations/).

The third thing I would say is to read a lot of books. Computer science is a broad field, and there are so many ways to experience and enjoy and contribute to it. It's helpful to have some exposure to different parts of the field. Some of the great ones include:

• Hofstadter, "Godel, Escher, Bach" (can be a life-changing book)
  
• Hofstadter, "Metamagical Themas" (also a really fun read if you liked G.E.B.)
  
• Gardner, "aha! Gotcha" -- fun book about paradoxes
  
• "How to Design Programs," and do the assignments (free online: https://www.htdp.org/)
• Abelson and Sussman, "Structure and Interpretation of Computer Programs," also free online
  
• Levy, "Hackers: Heroes of the Information Revolution" by Steven Levy (this is a fun story about the history of "hackers" and a bit about Silicon Valley)
• Steiglitz, "A Digital Signal Processing Primer: With Applications to Digital Audio and Computer Music" -- this was a life-changing book for me when I read it the summer before college. Computer science (and EECS) is about more than just programming!
• Sipser, "Introduction to the Theory of Computation" -- this is a junior-level textbook but you might be ready for it and enjoy it -- it's a great book

Number four, read these famous (and semi-depressing?) essays that every high-school student should read:

• Ursula Le Guin, "The Ones Who Walk Away From Omelas": https://www.utilitarianism.com/nu/omelas.pdf
• C.S. Lewis, "The Inner Ring": https://www.lewissociety.org/innerring/

Good luck, and please feel free to get in touch again if I can be helpful,

Keith

Advice on the CS faculty interview

Here is a bunch of advice that people gave me on interviewing for an assistant professorship in CS in 2014 that proved helpful at the time. Please take all of this with a grain of salt (I have never been on a tenure-track faculty hiring committee).

1. Enjoy it! It's a lot of fun to visit these places and get acquainted with a bunch of interesting people you would probably never talk to. You will keep bumping in to these people throughout your career.
   
   
2. Michael Ernst's advice is good: https://homes.cs.washington.edu/~mernst/advice/academic-job.html . Also read my interview with Eugene and Phil Guo: http://pgbovine.net/PhD-interview-eugene-wu-keith-winstein.htm
   
   
3. For the talk: Give MANY practice talks before your first real interview. Take advantage of any offers to sit and watch a practice talk. Giving the same practice talk multiple times to the same audience is not crazy -- you can take feedback, incorporate it, and then give the talk again. Consider videotaping your practice talk and then watching the video. If you can schedule yourself to give a talk somewhere that doesn't matter as much (e.g. a conference, or maybe a lower-ranked school) before the higher-stakes interviews, do it.
   
   
4. Remember that the talk is for a broad CS audience, and the theorists and AI people may have some strange questions based on their own disciplines or experience or what connections they see or don't see. It's good to be prepared for those questions before you get them for the first time at a higher-stakes place, because if you can give an erudite answer off the cuff to some question about a connection to something in somebody else's field (because you've heard it before!) it will make you look like a genius.
   
   
5. Pitching the talk to the audience takes some care. At some schools, you will have an audience of people who really know your area and want to ask tough questions. At some schools, there's really nobody who's an expert, and people just want to get a sense of, "Is this an exciting person with an exciting *future* agenda?" Try to figure out what kind of audience you have in each place [and be ready to switch modes as necessary]. Don't neglect the "future agenda" part of your talk.
   
   
6. Get the $60 Logitech R800 with the built-in timer and 5-minute vibrate warning and the green laser pointer. Practice your talk with the timer and vibrator for timing. Make sure you have a general sense of what the timer is supposed to be at at various points in your talk, so you know if you have to speed up or slow down. Really do aim to finish in 45-50 minutes (including questions in the middle), and be prepared that some places may want less than that.
   
   
7. Have backup presentation options. Make sure you can connect your laptop to the projector at each place. Carry all the dongles necessary. Carry your presentation on a USB thumb drive in various formats (PDF, PowerPoint, whatever) just in case. At Princeton, a colleague had trouble connecting his laptop to the screen and had to delay his talk by 20 minutes and people left before it began and there were no questions and he didn't get an offer. Don't let that happen to you.
   
   
8. Give yourself some rest time in the schedule if you can. If you can avoid it, try not to do two interviews the same week.
   
   
9. It can be overwhelming (especially the places that schedule you for two full days of 30-minute or 45-minute interviews plus three dinners). It's not crazy to take the list they give you and make index cards of the people you'll be meeting with. For each person, do two things: (a) write 3-6 words on the card that help you remember, "who is this / what is their deal?" Trust me, you are liable to forget when it's the 4th graph theorist you're meeting with at School X. (b) Read the CV and be prepared, if there's a lull in the conversation, to bring up, "Hey, here's a problem that youand I could collaborate on." Sometimes this might require going back six years in their publication history to find something you can talk about, but that's okay and people love that stuff. Remember that they are evaluating you as a possible (future) colleague, more than on the basis of your past work.
   
   
10. Soon after you're done with the interview, send everybody you met with a simple two or three-sentence thank-you email, just saying you appreciated meeting with them and enjoyed your visit and maybe that you liked meeting with their students. A lot of people don't do this (unless they are already faculty somewhere) but the pros definitely do it.
    
    
11. At the dinner(s), remember that you are still being evaluated. Limit alcohol and messy foods.
    
    
12. Try to meet with PhD students at every place you interview. (It's fine to ask to put this on your schedule if it's not there in the first version.) You'll enjoy getting a feel for the place through them. Also: at some schools, the Ph.D. students have approximately zero influence (e.g., MIT in my experience) and at some schools, the Ph.D. students have a surprisingly large influence (e.g. Stanford!). You'll never know this in general so just assume the Ph.D. students have lots of influence. From what I can tell, the #1 Ph.D. student evaluation criterion is, "Will this person be a good/kind/helpful advisor?"
    
    
13. Be prepared to discuss how your work relates or is independent from other people at the institution. E.g., if some faculty member is thinking, "What does she add when we already have Professors X/Y/Z?", it could be helpful to situate yourself relative to other people at the institution and show familiarity with their work (and be able to explain it to a nonspecialist).

Stock advice for undergraduates interested in doing a Ph.D. in computer science

Thank you for getting in touch! As you may know, Ph.D. students at Stanford are admitted by a department committee, and students usually rotate with three advisors during their first year, so that students are not beholden to any individual faculty member. I encourage you to apply in the fall (not just to us -- also consider MIT, U.C. Berkeley, U.C. San Diego, UCLA, U. Washington, Cornell, Carnegie Mellon, U. Illinois, Princeton, ETH Zurich, EPFL, University College London, Georgia Tech, U. Texas at Austin, Columbia, NYU, Tsinghua, etc.). If you are admitted, I would be happy to meet with you about the possibility of working together.

In the meantime, here is some stock advice for people thinking about doing a Ph.D. in computer science:

• Read some of the essays that people have written about "what grad school in CS is like." I did an interview on this with my friend Eugene Wu (https://cs.stanford.edu/~keithw/interview-2015-guo-wu-winstein.html), and our friend Adam Marcus (https://marcua.net/writing/gradschool-guide/) also wrote a guide after finishing his PhD. Our other friend Phil Guo also wrote a depressing book about his (not-so-good, but also not horrible) time in grad school at Stanford (available to Stanford students upon request -- Phil has had this removed from the Internet), and he ultimately ended up in a great job where he seems happy and productive (and now tenured) too.
  
  
• Read some of the advice for grad-school applicants, e.g. Michael Ernst's (https://homes.cs.washington.edu/~mernst/advice/) and Jennifer Rexford's (https://www.cs.princeton.edu/~jrex/advice.html) and Justine Sherry's (http://www.eecs.berkeley.edu/~justine/advice.pdf) and
  Mor Harchol-Balter's (https://www.cs.cmu.edu/~harchol/gradschooltalk.pdf) and Andy Pavlo's (https://www.cs.cmu.edu/~pavlo/blog/2015/10/how-to-write-a-bad-statement-for-a-computer-science-phd-admissions-application.html).
   
• Think real carefully about "Why do you want to go to grad school?" Do you want to use computational thinking to help people in a tangible way? Or do you want to learn about computer science for its own sake, as a quest for knowledge? Do you think you would enjoy a teaching-focused job, or an industrial research job, and these require a Ph.D.? All of these can be great answers, but they are different. What projects or independent activities have you done (things nobody told you to do) that you enjoyed or found satisfying? How can you aim to best continue that? (By contrast, "I did well in undergrad and would like to continue my education" is not a good reason to start a Ph.D. in computer science!)
   
• Consider taking time off between undergrad and grad school, or at least deferring for a year after you are accepted. Depending on the subfield, the people that do this often have a real leg up, because they can bring a nontraditional perspective to the table. There's little benefit in being "smarter" than everybody else in the group if all that means is that you are saying something first that somebody else was going to say anyway 90 seconds later. It's better to be the one contributing ideas (about new problems worthy of attack OR ways to solve them) or a point of view that wasn't going to get contributed at all. And the people who have exposed themselves to more diverse environments often have had more time to understand themselves and what kind of environment they need to build around themselves (advising, style of work) to be happy and productive. Depending on your advisor's style and the culture of the department, grad school can be almost a totally unstructured and self-directed environment (quite different from undergrad) so you really don't want to go into it as a sort of default. (If you are saying to yourself, "but I don't know what I would do during that year off," that is not a good reason to make grad school become your default! By contrast, if you are saying, "but I am in theory or another mathematically inclined subfield and literally the only way to get better at it is to keep doing it; there is nothing the outside world has to offer me," then maybe you are right -- theorists often do seem to adhere to this kind of thinking.)
   
• Start thinking about how to demonstrate (by December of the year when you plan to apply) to your letter writers that you have the initiative/resourcefulness/creativity/grit and can see a project through to completion even over obstacles. (Ideally, by participating in a research project that submits a paper for publication.) The letters of recommendation do matter a lot, probably more than anything else in the application, and the letters will ideally be from people that the readers can trust are well-calibrated to speak to your promise at doing CS research.
   
• Try to get on whatever mailing lists you need to to start attending the research talks at your college or university. (Some of this might be harder in the age of Zoom/economic collapse, but still...) This can vary based on what type of college you are attending, but if you are at a research university, there can be a lot of these: departments or research groups may have seminar series/colloquia, and then every doctoral student is going to have a public defense, and every job candidate who wants to be a professor is going to do a public "job talk," and at some places, every junior-faculty member who wants to get tenure has to do a "tenure talk," etc. These are almost always just open to anybody who wants to come.
  
  

Best regards,
Keith

What is Cambridge, MA known for?

Cambridge has been reinventing itself for four hundred years. It's a former farming village that became a major industrial town (New England Glass Co., Carter's Ink Co.) that became a seat of the 80s and 90s computer industry (VisiCalc, Lotus) that became a diverse intellectual and biotechnology capital.

“Is Computer Networks a boring area?”

Over on Quora, the question-and-answer Web site, my hackles were raised when I saw this question that seemed out of left field:

Is Computer Networks a boring area?

I'm asking this question since I'm looking at possible areas to do Masters in, and one of them is Computer Networks. [...] I've never met anyone who's been passionate about this field as of yet. I've met people from areas like data mining, AI, computer vision, robotics etc. who're fiercely in love with their subject. Thirdly, the very nature of this field made me ask this question. Innovation seems slow in general, especially hardware, and it appears that you get lost in a sea of implementing protocols and going through a lot of fine lines of code, instead of working on the next big thing.

I'd be glad if someone proves me wrong. Am I missing something here?

I couldn't help myself from piping up to defend the honor of computer networking (and discuss my own work in the process).

My answer:

Q: How accurate is Google Flu Trends?

Update March 14, 2013: In 2012–13, Google Flu Trends did not successfully track the target flu indexes in the U.S., France, or Japan. Here are my slides from a talk at the Children's Health Informatics Program (March 14, 2013).

Why this happened is a mystery. Google has said they will present their own view some time this fall. I think the divergence suggests that one needs to be careful about trusting these kinds of machine-generated estimators, even when they work well for three years in a row. It can be hard to predict when they will fall down. (And without an underlying index that is still measured, you might never know when it has stopped working.)

I did an interview with WBUR's CommonHealth blog in January and again in February, and spoke on the radio in January.

---

Q: The probability of success in each of a series of independent trials is constant. How can a 95% confidence interval for this proportion be obtained?

This is called the "binomial confidence interval," and there are a few solutions. Wikipedia discusses this here: Binomial proportion confidence interval

Q: Event A has a probability of 70% of happening within the year and event B, 40%. The events are independent and uniformly distributed through the year. What is the probability that they will occur within 3 months of each other?

There is more than one way to answer this question!

The ambiguity comes down to exactly how we interpret the statement that "Events A and B are uniformly distributed across the year."

FIrst interpretation: Events A and B are produced by a memoryless process with uniform hazard function. Every day, we wake up and Event A has a certain uniform probability of happening that day, the same as every other day. Event B is independent and has its own uniform probability of happening that day. If the event doesn't happen, we go to bed and wake up the next day, and it's the exact same story, with the same probabilities, all over again, just like "Groundhog Day."

Q: What is it like to have the process of video encoding or transcoding bring you to tears?

In 2005, we built a system to do the first amateur ATSC HDTV broadcasts. We broadcast MIT sporting events and the January "Integration Bee" (with play-by-play and color commentary, etc.) on the MIT cable TV system. (http://broadcastengineering.com/newsrooms/mit-sportcast-plan-calls-hd-telecasts, http://sportcast.mit.edu)

The plan called for us to build our own live HD switcher with wipes and other transitions, score overlay and ATSC encoder -- a commercial system was several hundred thousand dollars at that point. We had four HDV cameras connected via Firewire to a head-end computer, and used an array of 1U servers with nVidia cards to render an arbitrary scene with OpenGL (using a pipeline through four machines to paint the video from four cameras on the frame), then overlay the score and time, and finally encode with A/52 audio in ATSC-conformant MPEG transport stream and send out in QAM256 over the MIT cable system (http://web.mit.edu/sportcast/checkout/).

Some of the technical challenges proved especially difficult and I was up all night with them before a game. Getting four Firewire HDV cameras to talk to the same computer was a real pain, since these cameras generally have cheap chipsets and all want to talk on the same broadcast channel. (We got this working, but it was quite brittle since unplugging one camera would freeze the whole Firewire bus for about 1 second. In year 2 we switched to connecting the cameras to small Mini-ITX computers and then running them to the switcher over UDP on Ethernet.) Showing up at 10 a.m. at a volleyball game and having to explain to my colleagues that we STILL didn't quite have working video was painful!

The most challenging part was writing the MPEG systems stream encoder that would be ATSC-complaint -- in other words, writing a program to stitch together Dolby AC-3 audio and MPEG-2 video that would actually PLAY in sync on a real store-bought television without glitches. (The MPEG-2 video elementary stream was compressed by libavcodec, and the audio by liba52, but getting a compliant audio-video multiplex is a different story.)

This was difficult because those TVs do not exactly give you a lot of helpful diagnostic information. If you do it wrong, you see glitches, but these can be very rare (like once every 20 minutes!) and it's not like you get a debugging trace. 

ATSC has a lot of requirements you have to comply with, like you can't send a frame of video more than 0.5 seconds before it will be displayed, and if you break these you will see undefined behavior from the TV.

Getting all those pieces put together, so we could actually WATCH our sports broadcasts on a real HDTV in 2005 via the cable TV system without hiccups, was very satisfying and a great payoff for all our work. After spending umpteen all-nighters doing it and breaking numerous promises to my friends and colleagues to have it running earlier, I am sure I was brought to tears (of exhaustion and/or joy) when it finally worked.

Q: What are France's most remarkable contributions to the modern world?

How about:

Aviation (Montgolfier brothers, Robert brothers)

Moving pictures (co-invented by the Lumière brothers)

Electromagnetism (many contributions by Coulomb and Ampère)

Photography (co-invented by Niépce, also Daguerre)

Pedal-driven bicycle (Pierre Michaux, Pierre Lallement, and the Olivier brothers)

Inflatable automobile tires (Michelin)

Stethoscope (Laennec)

Gyroscope (Foucault)

Fresnel lens (Fresnel)

Calculator, probability, and much mathematics (Pascal, Fermat)

Galois theory (Galois)

Chaos theory, much mathematics (Poincaré)

Wavelets (Mallat, Meyer) and fractals (arguably Mandelbrot)

Baudot code and "baud" rate (Baudot)

Aqualung/SCUBA (Gagnan, Cousteau)

Fourier transform (Fourier)

Much music (Ravel, Debussy, Bizet, Saint-Saëns, Berlioz, Stravinsky, arguably Chopin)

Much, much art (Monet, Renoir, Cezanne, Seurat, Degas, Gauguin, Caillebotte, Rodin, Pissarro, Signac, arguably van Gogh)

More here: http://www.quora.com/France/What-are-Frances-most-remarkable-contributions-to-the-modern-world

Q: How many unique Tweets can ever be posted?

At least  (a number with 1,264 decimal digits), using the contents of the tweet alone. Plus there is all the metadata, which probably adds at least a thousand bits.

See https://blogs.oracle.com/ksplice... . It turns out that Twitter allows almost 2^31 choices per "character," at least when a tweet is first posted. (They decay over time...)

Unicode itself is a 20.1-bit system, but Twitter doesn't allow literally all Unicode scalar values. (E.g. it messes with < and >.) On the other hand, Twitter does allow the huge characters above the first 2^20, that is to say not Unicode, but below 2^31. (This is almost 31 bits anyway.)

Disclaimer: I have not checked this myself since writing that blog post in March 2010.

Q: Why is the SI second defined as 9,192,631,770 periods of the transition between two states of cesium-133?

In 1895, the astronomer Simon Newcomb published his "Tables of the Sun," based on observations of the sun's position from 1750 to 1892. (http://en.wikipedia.org/wiki/Newcomb%27s_Tables_of_the_Sun) These calculations turned out to be reliable enough that astronomers continued to use them until the 1980s.

Before 1956, the second was defined as the mean solar second, or in other words, 1/86,400 of the time the earth takes to spin around on its own axis and see the sun again each day. But because the moon's gravity and the tides are slowing down the earth's spin, this is not a stable quantity.

From 1950-1956, the international authorities agreed to redefine the second to be the "ephemeris second," based on the speed of the earth's orbit around the sun in 1900, as predicted in Newcomb's tables. The earth's orbit around the sun is not slowing down, at least not on anything like the effect on the earth's spin around its own axis. (In practice the ephemeris second is measured by looking at the moon's orbit around the earth and taking pictures of what stars the moon is near.)

Because Newcomb's tables cover observations from 1750 to 1892, the "ephemeris second" corresponds to the mean solar second at the middle of this period, or about 1820. (http://tycho.usno.navy.mil/leapsec.html)

Meanwhile, from 1952 to 1958, astronomers from the U.S. Navy and the British National Physical Laboratory measured the frequency of cesium oscillations in terms of the ephemeris second. (http://www.leapsecond.com/history/1958-PhysRev-v1-n3-Markowitz-Hall-Essen-Parry.pdf) Cesium is even more stable than the orbit of the earth around the sun.

There are a few ways to do the calculations that they show in the paper (having to do with exactly what period they observed over and whether they corrected for some subtleties re: the moon's orbit), giving results between 9,192,631,761 and 9,192,631,780. The average was 9,192,631,770.

In 1967, this became the official definition of the SI second, replacing the ephemeris second. But the reason the number is what it is is because Newcomb analyzed observations from 1750 to 1892, and the middle of that period is 1820, and that's how fast the earth was spinning on its axis in 1820.

Q: If one day is not exactly 24 hours and is in fact 23 hours, 56 minutes, shouldn't the error add up, and shouldn't we see 12 a.m. becoming noon?

You're right that a "sidereal" day is about 23 hours, 56 minutes, 4 seconds. But this is not a day in the everyday sense.

A sidereal day is how long it takes the earth (on average) to make one rotation relative to the faraway stars and other galaxies in the sky.

If you find a star that is directly above you at midnight one night, the same star will be directly above you again at 11:56:04 p.m. the next evening.

Similarly, if you were sitting on the star Proxima Centauri looking through a powerful telescope at earth, you would see Toledo, Ohio, go by every 23 hours, 56 minutes, and 4 seconds.

However, we don't keep time by the faraway stars -- we measure time by a much closer star, the sun! And we are actually in orbit around the sun, orbiting in the same direction that the earth is spinning on its own axis. From our perspective, the sun goes a little slower in the sky because we are also orbiting around it.

How fast are we orbiting around the sun? We make one full orbit every year, or roughly 366.25 sidereal days.

So after a year, the faraway stars will have done 366.25 rotations around the earth, but the sun will only have done 365.25 rotations. We "lose" a sunset because of the complete orbit. (The extra quarter day is why we need a leap year every four years.)

So there are 365.25 "mean solar days" in 366.25 "sidereal" days. How long is a "mean solar day"? Let's do the math: One sidereal day is 23 hours, 56 minutes, 4 seconds, or 86164 seconds. Multiply this by 366.25 sidereal days in a year, and you get 31557565 seconds. Divide by 365.25 solar days, and we get that a solar day is.... 86,400 seconds. That's 24 hours exactly!

It's this "mean solar day" (24 hours) that is the normal definition of day.

If you want to do the math more exactly, a sidereal day is 86164.09054 seconds, and a tropical year is 366.242198781 sidereal days. That works out very closely.

(P.S. Unfortunately, the earth's spin has been slowing down because the moon is sucking away the earth's energy. Every time the high tide of the Atlantic Ocean slams into the east coast of North America, the earth slows its spin a little bit. The definition of the second is based on the speed the earth was spinning back in 1820, and we have slowed down since then. As a result, we occasionally have to add in a "leap" second to the world's clocks. See http://online.wsj.com/article_email/SB112258962467199210-lMyQjAxMTEyMjIyNTUyODU5Wj.html?mod=wsj_valetleft_email)

Q: Why don't we see green stars?

Stars are black bodies in thermal equilibrium (http://en.wikipedia.org/wiki/Black-body_radiation). Their spectrum depends only on their temperature, and the shape of the spectrum is described by Planck's law (http://en.wikipedia.org/wiki/Planck%27s_law).

(from http://xkcd.com/54/, showing the spectrum of the cosmic microwave background radiation)

As a result, only some colors are possible: the ones that can be formed by a black-body radiator with this shape of spectrum. The line in the CIE diagram below shows the possible colors of black-body radiation, depending on the temperature:

(from Wikipedia's http://en.wikipedia.org/wiki/File:PlanckianLocus.png)

You will see essentially the same colors from incandescent light bulbs and toaster heating elements as from a star -- a 2700K tungsten filament will radiate light that appears to the human eye with the color corresponding to 2700K on the above diagram.

The "black body" curve does not go through anything you could really call green. 

Qualitatively, for something to appear green, it essentially needs to stimulate the medium-wavelength cones more than the long- and short-wavelength cones in the human eye. Black-body radiation is too broadband to do this.

Here, the colored lines represent the sensitivities of the three kinds of cones in the human eye. The dashed line is black-body radiation from a 5400K star, obeying Planck's law. Black-body radiation is way too broad to hit the "green" cones without also hitting the "red" and "blue" ones. That's why this light appears white.

Q: What is the safest, simplest, and most effective method to anchor an average-size sailboat?

There is technique (and many strong feelings) to anchoring, but I don't think there are any great secrets beyond what is taught in sailing classes. Just practice and patience and a lot of small things.

Usually anchoring can be done simply and without drama -- the need for experience comes when things go wrong. (Like pretty much 95% of things in sailing.) Of course it's a lot easier to anchor a Rhodes 19 in a nice lake with friends you sail with every weekend, versus anchoring an unfamiliar Beneteau 50 you just chartered off an unfamiliar island with inexperienced crew you are sailing with for the first time.

The way to be safe is to practice adequately, build up experience, and to keep learning from other sailors. US Sailing and ASA both teach "Basic Coastal Cruising" classes that including anchoring, and many sailors are flattered to help others learn this kind of thing. NauticEd (http://www.nauticed.org/sailingcourses/view/anchoring-a-sailboat) also has a $17 online course that is probably not bad.

Here are some general tips that they would teach you in a class:

1. Pick an appropriate anchorage, based on (a) shelter from wind and waves and lee shores (b) good holding ground [generally mud or sand will be preferred] (c) adequate scope, swing room, and depth under the boat.
2. Coordinate and practice with the crew. Arrange hand signals if necessary. Do not raise your voice. Speak in complete sentences. Use headsets if helpful.
3. Use an appropriate anchor. There are many strong feelings on this. For muddy or sandy bottoms, a lightweight-type (Danforth) anchor, appropriately sized to the boat, is generally fine. Of course there are many fancy anchors now available (Rocna, etc.) that are fine too.
4. Use appropriate rode. In the Caribbean, all-chain rode (with nylon snubber) is typically used because coral reefs can chafe nylon rode, and all-chain rode typically requires less scope. If using an all-nylon rode, allow 7:1 scope for overnight anchoring.
5. Consult a coast pilot (or cruising guide or similar publication) and nautical charts for information and warnings about the anchorage. In the BVI, the aerial photographs in "Virgin Anchorages" are very helpful for the first-time visitor to unfamiliar islands.
6. Realize that the difficulty varies based on the conditions and the time of day. Anchoring in pleasant weather in a familiar spot with the sun up is one thing. An unfamiliar anchorage at night in a gale with cold rain or spray and a slippery deck is different and calls for much more caution.
7. Cruise through the anchorage once before picking a spot to anchor. Don't just anchor in the first place that looks good. If there are other vessels already anchored, they have the right to set the anchoring method in use -- single bow anchor, Bahamian moor, two anchors off bow, etc. They have the right to ask you to move if you anchor too close. Feel free to slow down and ask the other vessels how much scope they have let out, etc.
8. When you do pick a spot, allocate appropriate swing room for changes in wind and tide. Confirm appropriate depth with your depth sounder and charts.
9. Assuming you are anchoring with a single anchor off the bow (the most common method): As helmsman, point the vessel into the wind and wait until ALL headway has stopped. Instruct the crew to begin LOWERING (not dropping or throwing) the anchor. Hopefully you have a working motorized windlass and have marked every 10 feet of the rode with little indicators -- these are both great conveniences.
10. For all-chain rode, I like to first pay out 3:1 scope, then back down on it with the engine at 2,200 RPM. Then I pay out to 5:1 scope. For nylon rode, I generally pay out 5:1 rode, then back down on it, then pay out to 7:1 scope.
11. With practice, you can confirm that the anchor has set by looking at how the rode "skips" across the surface of the water when it gets tensed up. In any event, don't leave the boat right away after anchoring. Confirm that you are not dragging. One classical technique is to sight a pair of objects off the beam and confirm that they retain their alignment (i.e. that the wind isn't pushing you back). Of course there are now GPS alarms for this kind of thing.
12. If the water is clear and warm enough, DIVE the anchor to confirm it has set. Sailors in the BVI swear by this. The corollary is that you should plan to arrive in the anchorage before the sun gets low in the sky, so you can still see the coral heads and the ground and your anchor.
13. If the anchor doesn't set, the first response should be to pay out more rode and see if it eventually sets. If that doesn't work, just pull it up, circle around, and do it again. Speak in complete sentences to the crew and explain that you are going to do it over again. Don't get angry if it doesn't work -- there's no shame in repeating the process 2 or 3 times. You'd much rather get it right than wake up with a "bump in the night" at 2 a.m.! If you still can't get it to set, you may have bad holding ground and have to pick a different spot.
14. Sometimes, in a crowded anchorage, when you are trying to do this, the proprietors of nearby vessels will come out on deck and look at you with the death stare. And they will bring their fenders out and tie them on. In a truly obnoxious anchorage, they will even talk loudly about the "amateur" or the "credit card captain" in their midst. These people are dicks and you can't let them get to you, but the way to be a responsible citizen is to (a) know your own capabilities and those of your vessel [i.e. practice maneuvering when you are out in the open!], (b) don't attempt anything unsafe or beyond your ability (c) don't hit anybody (d) keep your calm with the crew. No jumping around, no yelling, no waving your arms angrily. Speak in complete sentences.
15. If a nearby, previously-anchored vessel says you are too close and you have to move, you have to move. If they just give you the death stare and the full complement of fenders, consider yourself warmly welcomed. Dinghying over with treats and/or drinks can be a good way to introduce yourself.

Q: Does all "white noise" sound like the same hiss?

The answer is no: not all white noise sounds alike!

White noise can sound like "hissing" of a shortwave radio or it can sound like a Geiger counter (click..... clickclick............ click).

More:

A noise process is "white" if every frequency has the same power spectral density.

Any process where any two samples taken at different times will be statistically independent is white in this sense. In other words, if knowing the amplitude of the noise at time x tells us nothing about the amplitude at any other time, then the noise must be "white."

But there are many different-sounding processes that have this characteristic, because just knowing that two samples are independent does not tell us the distribution of the individual samples.

• One classical example is "thermal" noise, in which the samples are distributed according to a normal, or Gaussian, distribution. This is known as "white gaussian noise," and typically in communications will have been added to the signal we are interested in: hence, Additive White Gaussian Noise (AWGN). This sounds like "hissing."
• Another kind of white noise is "shot" noise, which can come from any Poisson process, including the particle decays heard by a Geiger counter. Here the individual samples aren't Gaussian deviates; they are impulses, either zero or big, and most of the time they're zero. But since knowing the time of one "click" tells us nothing about any other (and because each click carries all the frequencies), this is also white noise.

Q: What were some surprising court decisions?

American Council for the Blind v. Boorstin, 644 F. Supp. 811 (D.D.C. 1986), holding that the First Amendment required the U.S. Government to continue publishing the Braille edition of "Playboy" magazine.

Rodriques v. Furtado, 575 N.E.2d 1124 (Mass. 1991); Rodriques v. Furtado, 950 F.2d 805 (1st Cir. 1991). Upholding execution of 1 a.m. search warrant, signed by an assistant clerk-magistrate and not by a judge, of plaintiff's vagina.

The Trial of John Peter Zenger, 17 Howell's State Trials 675 (1735). Philadelphia attorney Andrew Hamilton persuades jury to acquit defendant on charge of seditious libel, on the grounds that anonymous essay criticizing New York government was true.

Marbury v. Madison, 5 U.S. 137 (1803). U.S. Supreme Court held that it did not have the authority to issue order to U.S. Secretary of State when petitioned as court of first instance, despite petitioner's legal entitlement to relief and Congress's purported grant of such authority in Judiciary Act of 1789.

Kyllo v. United States, 533 U.S. 27 (2001), holding police use of thermal imaging camera to take infrared photographs of petitioner's house was a search and was presumptively unreasonable without a warrant.

Q: What are the most impactful inventions created in Boston?

I think the telephone is probably the all-time top Boston invention, but also these:

1802 -- Modern navigation -- Bowditch

1886 -- Management consulting -- Little

1901 -- Disposable safety razor -- Gillette et al.

1914 -- "Tech"nicolor -- Founded in Boston by Kalmus et al.

1919 -- Trans-Atlantic aircraft -- Hunsaker et al.

1929- -- Instant photography (Polaroid) -- Land

1931 -- Stroboscopy -- Edgerton, Germeshausen et al.

1937 -- Use of Boolean logic to design "digital" circuits -- Shannon

1940-45 -- Practical radar -- Anglo-American military collaboration at MIT

1944 -- Mark I/II computers and first computer "bug" -- Aiken, Hopper et al.

1945 -- Hypertext -- Vannevar Bush

1951 -- Huffman code

1951 -- Random access memory ("core")-- Project Whirlwind

1953 -- PET scan -- Brownell

1953- -- Doppler radar -- Gordon

1956- -- Chomsky hierarchy

1957- -- Generative grammar -- Chomsky

1957 -- Confocal microscope -- MInsky

1957-61 -- Time-sharing (and some of what we now call virtualization) -- Project MAC

1958 -- LISP -- McCarthy

1961 -- Chaos theory -- Lorenz (and many others)

1961-2 -- Digital videogame (Spacewar!) -- Graetz, Russel, Wiitanen, Kotok 

1963 -- CAD -- Sutherland

1964 -- Minicomputer -- DEC

1964-5 -- Electronic mail -- Van Vleck / Morris on CTSS (also network email, Tomlinson in 1971)

1969 -- Apollo guidance computer that navigated to and landed on moon -- Instrumentation (now Draper) Laboratory

1970-90 -- Object-oriented programming and data hiding -- Liskov (and many others)

1972 -- Packet-switching and ARPANET -- Kahn, BBN, etc.

1973 -- Black-Scholes option pricing model -- Black, Scholes, Merton

1978 -- Practical public-key cryptography (RSA) -- Rivest, Shamir, Adelman

1979 -- Spreadsheet -- Bricklin and Frankston

1981-89 -- Copyleft/sharealike, GNU and free software movement -- Stallman

1995- - E-ink -- Jacobsen et al.

2000 -- Zipcar -- Danielson, Chase