Finally got around to putting up my slides and survey from my invited talk on open problems for deletion channels and related channels from SWAT online.
While there, Thore Husfeldt told me my idea for a "general CS book for high school students" has already been done -- in German. He gave me this link for the actual book, and another link for the notes/surveys the book was based on. Anyone know more about this project -- and if we can just translate a bunch of the chapters? (This project has not received much attention from me lately...)
Showing posts with label blog book project. Show all posts
Showing posts with label blog book project. Show all posts
Monday, July 21, 2008
Wednesday, May 07, 2008
Suresh Venkatasubramanian and the "Foundations" Book
Suresh Venkatasubramanian of the famed Geomblog has offered to co-manage this Future of CS: Foundations book project with me, so we hopefully will get more chapters soon. Our goal is to arm-twist a half dozen or so people over the summer, and then once people see it get started, maybe more will join. At least, now I have a good excuse to arm-twist Suresh!
I've had some people e-mail me with interest -- I'm very enthused, and I'm hoping you'll all follow through! (And if you haven't yet, please e-mail us with interest.) I think the key rules, again, to remember are that it should be written for smart high school sophomores, and that each chapter should include a "glimpse into the future", which I think of as a description of a specific, big, open problem that one hopes might be solved in about the next 10 years.
It also, I think, helps to think of right-sized "nuggets" for such chapters. (Although I'm open to more experimental approaches, a la Chazelle.) One person suggested they'd write a chapter on universal hashing, which I think is a great idea. Trying to cover all of hashing seems too big. But explaining the basics of hashing, and then the specific role of universal hashing and why it's interesting, seems just right.
I've had some people e-mail me with interest -- I'm very enthused, and I'm hoping you'll all follow through! (And if you haven't yet, please e-mail us with interest.) I think the key rules, again, to remember are that it should be written for smart high school sophomores, and that each chapter should include a "glimpse into the future", which I think of as a description of a specific, big, open problem that one hopes might be solved in about the next 10 years.
It also, I think, helps to think of right-sized "nuggets" for such chapters. (Although I'm open to more experimental approaches, a la Chazelle.) One person suggested they'd write a chapter on universal hashing, which I think is a great idea. Trying to cover all of hashing seems too big. But explaining the basics of hashing, and then the specific role of universal hashing and why it's interesting, seems just right.
Friday, April 25, 2008
Book Management
Talking about a "group-book" is a lot of fun. Actually putting one together, maybe less fun.
I like to think this project will be self-promoting, if it just gets started. A few people write their chapters. I put them online, blog about them, maybe push others to blog about them, a few more people think that's a good idea and look people are actually doing it, a few more chapters come in, and so on. Soon we have 20 or so chapters, and we think an actual book. (Maybe soon after that it catches on so well we get 40 chapters, and we make an omnibus.) To me, though, the hard part is getting started.
We need some rules of management, and if I'm currently the editor assigned to your paper for say SICOMP, you might now that management is not always my strong suit. (In self-defense, I'll say it depends on the situation. Corralling referees is not my best skill. And probably not corralling authors, leading to the failure the first time around.) So here, I'm happy to take advice. Send advice! Indeed, I've had a prod or two from people who'd be interested in co-managing/editing this project, so it won't be just me-- which is great!
I'll eventually work it out with co-editor(s), but here's my rough thoughts -- totally open to change.
1. We'll send annoying e-mail to people who we might like to write chapters. (Those who were on the old list, you're not off the list.)
2. People who want to write chapters can pick (and send me) a topic, so we don't get many people writing on the same topic.
3. Authors can make their participation public, so their name and a working title goes on the Web site, or private, so they can back out.
4. There has to be some notion of deadlines -- if you say you're going to write a chapter, after time x, you have to back out (and someone else might take the topic), or show significant progress.
5. I'd hope that several people might take time over the summer to write chapters, and then maybe some others over the fall, and so on. So if you think you can spare cycles over the summer to put a draft together, let me know!
I like to think this project will be self-promoting, if it just gets started. A few people write their chapters. I put them online, blog about them, maybe push others to blog about them, a few more people think that's a good idea and look people are actually doing it, a few more chapters come in, and so on. Soon we have 20 or so chapters, and we think an actual book. (Maybe soon after that it catches on so well we get 40 chapters, and we make an omnibus.) To me, though, the hard part is getting started.
We need some rules of management, and if I'm currently the editor assigned to your paper for say SICOMP, you might now that management is not always my strong suit. (In self-defense, I'll say it depends on the situation. Corralling referees is not my best skill. And probably not corralling authors, leading to the failure the first time around.) So here, I'm happy to take advice. Send advice! Indeed, I've had a prod or two from people who'd be interested in co-managing/editing this project, so it won't be just me-- which is great!
I'll eventually work it out with co-editor(s), but here's my rough thoughts -- totally open to change.
1. We'll send annoying e-mail to people who we might like to write chapters. (Those who were on the old list, you're not off the list.)
2. People who want to write chapters can pick (and send me) a topic, so we don't get many people writing on the same topic.
3. Authors can make their participation public, so their name and a working title goes on the Web site, or private, so they can back out.
4. There has to be some notion of deadlines -- if you say you're going to write a chapter, after time x, you have to back out (and someone else might take the topic), or show significant progress.
5. I'd hope that several people might take time over the summer to write chapters, and then maybe some others over the fall, and so on. So if you think you can spare cycles over the summer to put a draft together, let me know!
Thursday, April 24, 2008
Writing a Chapter, and Answering Some Questions
Yesterday, I posted the chapter I had drafted on codes for the hoped for book on CS aimed at high school sophomores. (You'll also note I now have a link to Bernard Chazelle's marvelous essay, The Algorithm: Idiom of Modern Science. Bernard agreed to "donate" this essay to this book projects two years ago, and has again given permission for its use.) I just wanted to clarify, the chapter did not take long to write. There was some background time in thinking about what I wanted to present, and time for looking a few things up. The actual writing, though, took something like 3 half-days during the summer, and that includes pictures. While your mileage may vary, I don't think this project should be a time sink for anyone. I'd like to think that if you made it a priority, it could be done fairly quickly.
The chapter was designed to cover what I think are important features:
Other questions:
1) Why not do it in a wiki?
Answer: I've explained some in comments-- I don't think a wiki is appropriate for a "creative writing" exercise. Also, I'd like some actual commitment from authors, and I'd like them to get credit for their work. (If this all works out, you can put this on your next NSF grant application as your broad educational service.)
2) Why focus on "theory"?
Answer: It's that perfect/good thing. I'd like something coherent, that I'm qualified to manage, that can be done in a reasonable time frame. That means some focus, and I'm choosing to focus on theory. (And theory, in my mind, needs the PR.)
If this works out, we can expand to other volumes. Heck, I'll manage/edit volume 2, communications and networking. Then I'll hand it off to someone else.
3) Who do you want to volunteer?
Answer: I'll be honest -- I have a very strong preference for Ph.D.'s (over graduate students), and I'd generally prefer "name" professors/research scientists -- we need at least some of those, so we can start developing some of that cult of personality in our field, and so the book will carry some weight with publishers and other outsiders. But I'd be open to any and all good ideas.
4) Timeline?
Answer: Well, I'll talk about "management" more next post. But I'd hope that a dozen or so people could be convinced to take some time over the summer -- maybe a week or so -- and write up a chapter draft. But since last time that sort of schedule seemed too optimistic, I'd be thrilled to get chapters by the end of the year....
Next post: ideas on management?
The chapter was designed to cover what I think are important features:
- A simple introduction, based on (hopefully) easy-to-follow examples.
- An explanation of why this is important in "the real world".
- Important past results, that are known and understood. (Here, Reed-Solomon codes and LDPC codes.)
- A goal for the future. (In this case, network codes, and figuring out how they might actually be used in networks.)
- Links/pointers to relevant references.
Other questions:
1) Why not do it in a wiki?
Answer: I've explained some in comments-- I don't think a wiki is appropriate for a "creative writing" exercise. Also, I'd like some actual commitment from authors, and I'd like them to get credit for their work. (If this all works out, you can put this on your next NSF grant application as your broad educational service.)
2) Why focus on "theory"?
Answer: It's that perfect/good thing. I'd like something coherent, that I'm qualified to manage, that can be done in a reasonable time frame. That means some focus, and I'm choosing to focus on theory. (And theory, in my mind, needs the PR.)
If this works out, we can expand to other volumes. Heck, I'll manage/edit volume 2, communications and networking. Then I'll hand it off to someone else.
3) Who do you want to volunteer?
Answer: I'll be honest -- I have a very strong preference for Ph.D.'s (over graduate students), and I'd generally prefer "name" professors/research scientists -- we need at least some of those, so we can start developing some of that cult of personality in our field, and so the book will carry some weight with publishers and other outsiders. But I'd be open to any and all good ideas.
4) Timeline?
Answer: Well, I'll talk about "management" more next post. But I'd hope that a dozen or so people could be convinced to take some time over the summer -- maybe a week or so -- and write up a chapter draft. But since last time that sort of schedule seemed too optimistic, I'd be thrilled to get chapters by the end of the year....
Next post: ideas on management?
Wednesday, April 23, 2008
The TheoryCS Book
I'm glad to see interest of various kinds in the Book on Computer Science (I really need to come up with a catchy name) I talked about last post. And yes, as many of you correctly interpreted, I'm looking for volunteers!
To flesh the idea out for you, here is (with some small updating) the original proposal I sent out for what I had in mind. For those who don't like clicking, here are what I wrote as the main rules:
If you're wondering what such a chapter might look like, I have my chapter from back in 2006 available. (It's on coding, naturally.) I'll talk more about this chapter, and how much work a chapter is, next post.
To flesh the idea out for you, here is (with some small updating) the original proposal I sent out for what I had in mind. For those who don't like clicking, here are what I wrote as the main rules:
- The intended audience you should have in mind when writing a chapter is smart high school sophomores. I see this as the most important rule. The goal is a book (or, more concretely, a collection of chapters) the general populace can pick up and read, to learn about computer science and why it is interesting. We want to hear people say: I decided to try computer science because of this book.
This rule has some corollaries. First, fewer equations, more pictures. Second, lots of examples. Third, simple language. I do not mean to suggest that we talk down to the audience, or assume that they are mathematically ignorant, but that we assume as little as possible, and try to reach the broadest audience.
- Each chapter should explain something already known and understood, and why it is significant.
- Each chapter should explain a specific, but big, open problem that one hopes might be solved in the next 10-20 years, but probably not before that.
- Each chapter should be roughly 15 book pages. If we can have 20 chapters, that will be about 300 pages, which is plenty. That's a guideline; I expect some variance.
- Each chapter should include at least 3 easily available references for more information.
If you're wondering what such a chapter might look like, I have my chapter from back in 2006 available. (It's on coding, naturally.) I'll talk more about this chapter, and how much work a chapter is, next post.
Subscribe to:
Posts (Atom)