Tuesday, July 17, 2018
The Sweet Heartbreak of Parenting
He doesn't even realize it (in fact, he's not even home right now), and would probably think I was a little crazy for its affecting me at all. Who knows, maybe I am a little crazy, but I decided I needed to write it down somewhere. Who knows--somebody might find it a little entertaining or informative, or something.
My wife took my kids on vacation, so they're not around the house right now. I was doing a little house-cleaning (yes, I actually do that, regardless of what my wife claims). Cleaning the bedroom shared by my two youngest sons (8 years old and 5 years old), I noticed that all their stuffed animals were on one of the beds. Usually they fight over the stuffed animals, and who can get the most on any given night. Once they've divided them up, each jealously guards his treasure trove with little short of his life. Seeing them all on one bed was a little surprising, to say the least.
I started to pick up a couple of the animals to put them back where they belonged, and saw there was a slip of paper under them. On it was written, in an 8 year-old's handwriting: "Here Ben. I'm almost nine now. I don't need stuffies any more."
I can't help thinking that my sweet little boy just declared that his childhood is over. He's a big boy now. I guess I can understand that. I remember when I too wanted more than anything in the world to be "big"--to be a grown-up. In some ways, I can't blame him. Being a grown-up definitely has some good points to it. I love being a father. Having a family is by far the greatest privilege of my life.
Even so, I hope--almost more than anything else I can think of right now, that by the time they get back from vacation, he's forgotten the note, and they fight at least a little bit over the stuffed animals. The fighting may upset my wife a little bit, but if they don't fight, it really does mean he's leaving behind a little more of the sweet baby boy I remember. I know that's inevitable anyway, but I hope he hangs on to a little bit of it at least a little longer.
You've probably heard it before, but I'll repeat it again: if you're a parent, treasure the time with your children. Even when they drive you crazy with noise and fighting and running and being out of control, try to remember: that'll end soon enough. Do your best to be happy with it while it lasts.
Friday, June 16, 2017
Privilege and Idiocy
The first few statements
1. I am white.
2. I have never been discriminated against because of my skin color.
3. I have never been the only person of my race in a room.
4. I have never been mocked for my accent.
5. I have never been told I am attractive “for my race.”
More selections
-
I have never been raped.
When I went into the military (US Air Force, in 1984) part of the medical examination involved a doctor pushing a finger in your sphincter. To my thinking, this was simply a normal part of a medical examination, to which tens of thousands of people are subjected every year.
-
I’ve never been told that I’m overweight or “too skinny.”
I have a little more sympathy for people who are severely underweight. This can be much more difficult to deal with. If you're honestly anorexic, seek help if you aren't already getting it.
-
I have never been cyber-bullied for any of my identities.
The Verdict on the Test
Worse than the individual items in this list is the basic attitude it shows in general. Essentially all of the questions really seem to revolve around one point: a belief that if people act as if they like or admire me, that’s “privilege”. It seems to me that it does a fair job of testing one thing. I’m not a psychiatrist, but I see little choice but to conclude that regardless of the actual score you get in this test, if you consider the test or score as having even the slightest bearing on reality, you should probably seek professional help immediately (no, I’m not being sarcastic at all—I’m 100% serious).Real Privileges
I believe I am extremely privileged. Let me list a few of the factors in my life that I think have been real privileges:1. I learned to read at an early age.
2. I had a large supply of books available at an early age (for people less ancient than myself, feel free to substitute Internet access—it not only provides much more information, but makes it dramatically easier to access as well).
I’ve lumped these together because they largely go hand in hand. They are also absolutely immense privileges—if you checked off every one of the items in the test under discussion, it still means far less than having learned to read.
For the vast majority of human history, large parts of the population were in danger of starving to death, or being a casualty of war (or both)--often many times in their lives. Although I’ve never actually been in danger of starving to death, I’ve gone for two or three weeks at a time without an actual meal. Even that degree of hunger dwarfs the trivial nonsense discussed in this test.
Even for people whose lives weren’t directly endangered, anything approaching “fulfillment” from life was far beyond most peoples’ dreams throughout most of human history. Slaves and serfs frequently had no choice at all in their lives, and even nominally “free” people frequently had little real choice, and essentially no chance at “upward mobility’ at all.
Even compared to when I was a child growing up, the amount of information people have easily accessible is absolutely astounding. Being able to type a paper for school on a computer and correct spelling errors easily instead of writing it by hand and starting over if you made too many spelling mistakes--there's no way to meaningfully compare these.
7. Living in the western world
Even today, many people are raised in enforced ignorance. There are still people in danger of dying from starvation or diseases to which cures and/or effective vaccinations are well known. A great deal has been done relatively recently (much thanks to the Bill and Melinda Gates Foundation, among many others), but there’s seriously a lot left to do, and areas where such assistance is routinely refused as well.
Conclusions
1. The test is utter nonsense2. There are real privileges—and they’re huge compared to the trivial nonsense covered by the test questions. They’re also very close to universal among essentially everybody with access to the test though. We, the people with easy access to the Internet are much more alike than different—and all of us are almost supremely privileged.
Thursday, February 4, 2016
Raw loops vs. standard algorithms revisited
I didn't think his solution using STL algorithms took full advantage of what the library really has to offer. He did use std::mismatch to find the point at which items mismatched, which is clearly a good thing. The rest of the code, however, looked to me like he was thinking primarily in terms of loops, and merely changed the syntax from a for loop to use std::for_each instead.
At least in my opinion, this doesn't really gain much. At least in my observation, using `std::for_each` is most often a mistake. It's still little more than a generic loop. The name of algorithm used should usually give me a good idea of what some code is doing, but `std::for_each` really doesn't--I have to look at the content of the "loop" to get any idea of what it's really doing.
In this case, the basic idea (simplifying a tiny bit) is to take the paths to two files, and find a relative path from one to the other. The two paths have already been parsed into components held as strings in a vector, so our job is to generate a path with "../" for all the leading components that are identical, then copy the components from one of the vectors into the output after that (and finally append a file name on the end).
Just going from that description, some choices seem fairly obvious, at least to me. To generate the leading part of the path, we probably want to use `std::generate`. Then to copy the remaining elements, we probably want to use `std::copy`. Although it may not be quite as obvious just from the wording, `std::fill_n` actually works out a little better than `std::generate_n`.
Our result is going to be in the form of a string. We want to append strings together to create the whole output. One obvious way to do that is to use an `std::stringstream`. So, let's start by doing a tiny bit of fudging to turn this into a standalone example (I don't think this has a significant effect on what we're doing). Rather than extract the vectors from a cache as he did, let's start with a couple of fixed vectors:
std::vector a = { "dir1", "dir2", "dir2_1", "p" };
std::vector b = { "dir1", "dir2", "dir2_2", "p" };
Then we do the step that (I think) he got right:
auto pos_p = std::mismatch(a.begin(), a.end(), b.begin(), b.end());
From there, we can define our stringstream, and an iterator to give us access to it in a way that's friendly to standard algorithms:
std::ostringstream path;
std::ostream_iterator(path, "/");
Then we want to generate the leading part, then copy the trailing part of the result path:
std::fill_n(out, pos_p.first - a.begin(), "..");
std::copy(pos_p.second, b.end(), out);
At least in my opinion, this makes it much more apparent that the first part of the path is composed of instances of ".." separated by "/", and the second part is composed of elements from the second vector (again, separated by "/").
This hasn't shortened the code a lot (maybe not at all), but it has (at least in my opinion) made the actual intent much clearer.
For better or worse, I've seen a fair number of arguments/claims that using a stringstream and an ostream_iterator can produce substantially slower code that doing the job by appending data directly to a string. I haven't tried to run a benchmark to verify this, but for the moment, let's assume you were working with a compiler for which it really was true (and true to an extent that the slow-down was a serious concern).
If so, we could still use roughly the same structure--we just have to define our own iterator to handle appending things to a string instead of inserting them into a stringstream. We lose some versatility (we can only insert things that are already strings, rather than handling all sorts of conversions to strings like a stream can), but maybe we gain enough speed for that to be worthwhile. So, if we decide this is really worth doing, implementing it is pretty straightforward (moreso than most people seem to think).
Our iterator to append to a string (with a little front-end function to avoid having to pass template parameters explicitly) can look something like this:
#include
template
class appender_t : public std::iterator{
String *s;
String sep;
public:
appender_t(String &s, String sep) : s(&s), sep(sep) { }
appender_t operator=(String const &add) {
*s += add + sep;
return *this;
}
appender_t operator++() { return *this; }
appender_t &operator *() { return *this; }
};
template
appender_t appender(String &s, String sep) {
return appender_t(s, sep);
}
Most of this is boilerplate--the only parts that really implement any logic at all are the constructor and `operator=`. The constructor is still pretty trivial: it just saves a pointer to the two strings used to initialize it. The assignment operator isn't much more complex--it just says when a string is written through the iterator, we append that string plus the specified separator to the string we stored.
Using this, the rest of the code barely changes at all. We define our output and iterator a tiny bit differently:
std::string path;
auto out = appender(path, "/"s);
From there, however, virtually nothing has changed (which is pretty much the point of using iterators to start with--they isolate the algorithm from the container, so algorithms can work with different kinds of containers.
So anyway, using that we can eliminate the pesky `std::stringstream` intermediary, so we're just appending directly to a string, just like we were to start with--but now doing it with algorithms that actually fit the task at hand.
A complete, working copy of the final code is available on Coliru.
I should probably add that this code is purely an attempt at producing exactly the same result as the code in the original article. As Luigi Ballabio was kind enough to point out in a comment, that's not really the right thing to do.
Saturday, August 9, 2014
Do Quora users actually have brains at all?
The question was: "Why do Americans seem to be so scared of a European/Canadian style of healthcare system?" The top-voted answer (at least as I read this) is: "In a word - fear" (yes, I cut and pasted that--if you think I must be making this up, I'd consider that entirely forgivable). Now, it's true that the author does go into more about detail about what he thinks drives that fear, but "fear" is what he gives as the actual answer. So, "Why do Americans seem to be so scared" is answered with "fear", and (at least as I write this) that has received literally thousands of up-votes.
Unfortunately, the "answer" goes downhill from there. The author (a "Dan Munro", who gives an unsupported claim of "knows some healthcare stuff"). He gives four supposed reasons for his claim of "fear":
- A false assumption (with big political support) that a system based on universal coverage is the same thing as a single payer system.
- A fear of "rationing" - which was set ablaze by Sarah Palin and her cavalier remarks about "death panels."
- An attitude and culture of what's loosely known as American Exceptionalism.
- A fierce independence that has a really dark side (which he goes on to explain as an attitude that when/if anybody "fails", it's considered their own fault).
To put it simply, I've yet to see any real support for any of these. The only one that seems to have even the slightest basis in reality is the second. It us true that a few (Sarah Palin being the most obvious) have tried to generate fear on this basis. It may even be true that it has succeeded in at least some tiny number of cases. The vast majority of people who oppose (further) government regulation of healthcare, however, seem to find it nearly laughable.
The most ridiculous, by far, is the claim of "American Exceptionalism". While frequently advanced (relative to an almost surprising range of subjects), this seems to be a pure straw-man at least with respect to this question. I have quite literally never heard anybody dismiss an argument on the basis that "it came from Canada, Europe, or outside the US in general, and we can't possibly learn anything from 'them'." At least in my experience, it simply doesn't happen. I obviously can't possibly know exactly what every single person in the US believes or feels, but I've yet to see or hear anything that gives even the slightest shred of support for this particular belief.
He then goes on to quote some of the usual statistics about how much of the US GDP is spent on healthcare, and a study about deaths from preventable medical errors in US hospitals.
Unfortunately, the numbers he quotes (210,000 to 440,000 annually) seem to be open to a great deal of question. Depending on which study you prefer to trust, the number is might be as low as 32,500 annually (and no other study I can find gives a number any higher than about 100,000 annually). Despite this, the largest number he can find is quoted as if it were an absolute fact that's not open to any question at all.
Worse, however, is a much simpler fact: he makes no attempt at comparing this result to the numbers for other countries, and (perhaps worst of all) he makes absolutely no attempt at telling us how the change(s) he apparently advocates would improve this in any way. So, even if we assume he's gotten the factual part right, we have absolutely *no* reason to believe any particular plan will improve it in any way.
Although I can't claim to speak for the US in general (or anybody else at all) in this regard, that leads directly toward a large part of the reason I have personally found it impossible to generate any enthusiasm for the plans that have been advanced to change healthcare in the US.
The usual argument seems to run something like this. The advocate starts by pointing to US citizens paying far more than others for healthcare, and having shorter average life spans. He then uses that to support his claim that we need to pass some particular health care plan he supports.
Unfortunately, nobody making such arguments seems to (even try to) "connecting the dots" to show exactly how or why *their* plan will improve the problems they ascribe to the current system. Virtually none can provide any real breakdown of US healthcare costs vs. costs elsewhere, to indicate exactly what is driving the higher costs in the US. Absolutely none (that I've seen) takes any next step toward showing how their plan will fix those problems.
When I've participated in a discussion, it usually runs like this:
Them: Our current system is broken. We need to pass bill X to fix it.
Me: What will X fix, and how will it fix it?
Them: Didn't you listen? It's really broken!
Me: Okay. What will X fix and how will it fix it?
Them: I'm telling you, it's seriously broken!
Me: Yes, I hear that. Now, can you tell me what X will fix and how it will fix it?
Them: [usually starting to get pretty loud by now] Damn it! What will it take to get it through your head that it's broken? Are you a complete idiot?
This seems to go on about as long as I'm willing to participate. I've yet to hear a single advocate of a single system actually answer a single real question about what it will fix, how it will fix it, what costs will be reduced, how much they will be reduced, etc. No matter how often you ask, even about relatively simple details of any proposed program, nobody seems to have a single answer about what they think it will accomplish, not to mention providing any reason for me to believe that it really will accomplish that.
If you'll forgive a (mildly) medically-oriented metaphor, Quora seems to be infected with a similar culture. Questions pre-suppose a given answer (in this case, that resistance to changes in health-care stems from fear rather than things like lack of information). This is certainly far from the only answer that seems to do little beyond echoing back the question, with only straw man arguments to support it, then a rather disjointed attempt at denigrating what the author dislikes, without even an attempt at claiming that his "solution" would really fix the supposed problem(s) he cites, not to mention actually providing anything similar to real evidence that of improvement.
So yes, although Quora users undoubtedly do have brains, it certainly appears to me that failure to actually put them to use is somewhere between common and rampant.
Considering questions more specifically about health care: I, for one, am fairly open to the possibility of reforming how healthcare is run in the US. So far, however, I've yet to hear anybody advance a coherent, understandable argument in favor of any proposed plan. Most simply seem convinced that the current system is *so* badly broken that absolutely any change would have to be an improvement. Even the slightest study of history, however, indicates that there is no such thing as a situation so bad that it really can't get worse.
Monday, December 2, 2013
Inheritance, templates, and database models
At the time, multiple inheritance had recently been added to C++. I noted that single inheritance corresponded closely to the hierarchical database model, and multiple inheritance corresponded closely to the network model.
As I'd guess most people reading this are well aware, most databases have long-since switched to (something at least intended to be similar to) the relational model and there are formal proofs that the relational model is strictly more powerful than either the hierarchical or the network model. That led to an obvious question: what sort of program organization would correspond to the relational model?
I would posit that C++ templates (especially function templates) correspond closely to the relational model. Rather than being restricted to situations like "X is derived from Y", we can instantiate a template over any type satisfying some relation--though in the case of a template, the relation is basically a set of operations that must be supported by the type rather than a set of values that must be stored in the database.
The major problem with templates (by themselves) is that we have very little control over how that matching is done. The matching criteria are difficult for most people to understand, and even harder to control. Even at best, the control currently available (e.g., via static_assert) is clumsy use and hard to read.
Concepts refine that capability considerably. Concepts are similar to defining foreign keys in a database. Right now, what we have is similar to a bunch of tables, with some fields (or sets of fields) in some of those tables used as foreign keys in other tables--but no declarations of what is supposed to be used as a foreign key, and therefore no way for the compiler to (a C++ equivalent of) enforce referential integrity.
As I'm sure most programmers are already well aware, a key (no pun intended) capability of a relational database is defining relationships between tables so the database manager can enforce referential integrity. That is similar to what C++ Concepts add--something at least roughly equivalent to foreign key declarations in a database, defining what relations are intended and should be enforced by the compiler.
Now don't get me wrong: I'm not trying to write a sales-pitch for Concepts, or anything like that. Rather the contrary, I think quite a few people have probably done a better job of explaining them and how they improve C++ than I've even attempted. What I find much more interesting is seeing (or maybe just imagining--others may disagree with my ideas) a fairly clear similarity between two types of programming that (I think) many probably see as quite unrelated or perhaps even directly opposed.
Sunday, August 11, 2013
When is a question about a puzzle, and when is it really about programming?
This is the problem: There are two players A and B. Player A starts and chooses a number in the range 1 to 10. Players take turn and in each step add a number in the range 1 to 10. The player who reaches 100 first wins.In the program, player A is the user and player B is the computer. Besides that the computer must force a win whenever possible. For instance, if the player A reaches 88 at some point, the computer must choose 89, as this is the only way to force a win.
A user then voted to close the question, with the comment that it was about a logic or math problem rather than about programming.
Personally, I disagree with that. In fact, I think it's an unusually good example of a problem for learning to program.
Allow me to digress for a moment. The first step in learning to program is learning to take some algorithm, and transcribe it into the syntax of a chosen programming language. Now, it's certainly true that being able to express an algorithm in a chosen programming language is important. It's not just about syntax either. Just for example, expressing an algorithm well often involves knowing a great deal about the accepted idioms of that language as well. Nonetheless, the whole business of simply writing code is only the last step in a larger, usually much more involved process.
That larger, more involved process deals primarily with finding solutions to problems. Only once we've found a way to solve the problem can we write code in our chosen language to carry out that solution. Now, it's certainly true that in many cases, we want to use an iterative approach to a solution -- we don't expect the first code we write to be the final an ultimate solution to a real problem for real users. Nonetheless, when we write code, we need to write it to do something, and we need to decide on that something before we can write code to do it.
Now, the question already notes that 89 is a winning "position". That immediately leads us to two questions: 1) why is it a winning position? 2) Based on that, can we force a score of 89?
The answer to the first is simple: 89 is a winning position, because from there our opponent can't reach the goal of 100, but no matter what move he makes, in the subsequent move we can reach 100. That is so because 100-89 = 11. The smallest move the opponent can make is 1 and the largest is 10, so no matter what he chooses, the remainder will be between 1 and 10, and we can win.
That leads fairly directly to the next step: we can force a score of 89 if we can reach a score of 78 -- and we can force a score of 78 if we can reach a score of 67 (and so on, counting backwards by 11 until we reach 12 and finally 1.
Therefore, the first player can force a win if and only if he chooses 1 in his first turn. If he chooses anything larger, the second player can choose a number that gives a result of 12, guaranteeing himself the win.
This is a large part of why many of the better computer science programs have classically used (more or less) functional languages like Scheme, and emphasized recursion as a basic primitive. It's not really about recursion as a flow control primitive or anything like that. Yes, we've known for years that a for loop, while loop, etc. can be expressed via recursion (and likewise that anything we can do with recursion can also be done via other flow control primitives).
What's important isn't that recursion allows arbitrary flow control. What's important here is the way of thinking about and approaching the problem. Recursion just gives a simple and direct way to approach the problem: instead of solving for 100, if we know that 89 is a winning position we can solve for 89 instead. Note: we could just about as easily think of it mathematically. Instead of thinking of this as a case of recursion, we could think of it as an inductive proof. The steps I've outlined above are essentially the same as those for an inductive proof.
Now, it's certainly true that this approach isn't suitable for every programming problem. If you're dealing with something like: "why is this text field being computed as 134 pixels wide when it should be 135?", chances are recursion isn't going to enter into your thinking, and might not be a lot of help if it did.
Nonetheless, if you're trying to solve a problem, and can define one step toward a solution, chances are very good that an inductive/recursive approach will be useful in solving the whole problem. It's most obvious in a case like this where the problem and solution are mathematical, so we have a well-defined line from problem to solution, but it can also apply to quite a few other cases as well (including the previous problem about text width, which it's sometimes useful to think of in terms of "some arbitrary string followed by one character", and continue with shorter and shorter strings until we reach only one or two characters).
Thursday, January 24, 2013
Word frequency counting
After seeing his follow-up After the Jump, I decided one point could stand being addressed. In his followup, he says: "About reading a file using iostream. Don't. It is slower and difficult to manage for complicated file formats. This application was trivial but I will avoid in the future."
On this subject, I have to disagree. Iostreams do have some shortcomings, and some implementations are also (un-)fairly slow. Nonetheless, they also have some pretty major advantages if (a big if, here) you use them well. I hope he won't feel insulted if I point out that (at least in my opinion) there are better ways to use iostreams than the way he did it.
For those who haven't read his posts, the task he set was quite simple: count the unique words in a file. He decided to do a bit of parsing, however, so that something like "one,two" would not include the comma. Unfortunately, he didn't (IMO) do this very well, so that would be counted as "onetwo" instead of treating "one" and "two" as separate words.
That brings up the obvious question: can we read those correctly, without doing extra parsing to patch things up after the fact? Of course, there's not a whole lot of suspense -- pretty much anybody with an IQ higher than a mosquito's can probably figure out that I wouldn't ask the question in the first place unless the answer was yes.
The way to do this (or the way I'm going to advocate in this post, anyway) depends on part of how iostreams are designed. When you read a string from a stream, any leading whitespace characters in the stream are ignored, then non-whitespace characters are read into the string, and reading stops at the first whitespace.
About now, you're probably thinking: "Yes Jerry, we already got past the 'IQ higher than a mosquito's' question; I already knew that!" What you may not know, or at least may not have seriously considered (though a few of you probably have) is exactly how the iostream determines what is or is not whitespace. The answer to that is a little complex: the iostream has an associated locale. The locale, in turn, contains a ctype facet -- and the ctype facet is what determines classes of characters.
So, to ignore those commas (and hyphens, etc.) we simply need a ctype facet that classifies them as white space, tell the iostream to use a locale containing that ctype facet, and we can just read words. Since it seems reasonable to me that (for example) "Jerry's blog" should be read as two words, not three, I'll classify upper and lower case letters and apostrophes as "alphabetic" and everything else as "white space".
Using that, the code we get code that's fairly simple, readable, and as a bonus, even a bit faster (though that wasn't really the intent).