Another fun one to trip people up: A car travels around a 1 mile track. It goes around the its first lap at 30 MPH. How fast does it need to go on its second lap to average 60 MPH?
I imagine you'd probably have to go with 1000 miles to get numbers in a usable range:
10 MPG = 100 gallons per 1000 miles
20 MPG = 50 gallons per 1000 miles
33 MPG = 30 gallons per 1000 miles
50 MPG = 20 gallons per 1000 miles
FWIW, most gas tanks seem to be sized around a 300 - 350 mile range for the expected city fuel economy of the car. So, 1000 miles gives you an idea of the "cost of 3 fill-ups."
It's not difficult at all. But it's only truly "obvious" in retrospect.
When my wife got her iPhone, I had to tell her how half the UI pieces worked, since she wasn't getting very far straight out of the box. Features such as "pinch to zoom", etc. are only obvious in retrospect. I only knew about these details because I read about them on Slashdot or articles linked from here. When I borrowed a friend's iPhone for a minute, I had to ask how to cut/paste, since I didn't actually know and I wasn't sure what to do.
Good UIs are highly discoverable and forgiving, and once learned, easily remembered. The best UIs do this to the point of being mistaken as "intuitive", but that's really a misnomer. For example, why, prior to ever seeing an iPhone, would my intuition tell me "pinch to zoom in/out" is the way to go? But once you've done it, you develop that association fairly quickly and then and only then it feels natural. To be truly intuitive, that means you should be able to figure it out driven only on intuition and things you've seen before alone. If it's only "intuitive" after you've seen it once, it's not intuitive.
A feature might be discoverable, though, and it's good to make the discovery process as intuitive as possible. For example, with the pull down menus of yore, your intuition might say "Oh, that's probably under the File menu" or the like, and if the UI designers have done a good job with their consistency, then it will be easy to develop that sort of intuition. Small touch screens on portable don't offer as many opportunities to develop that sort of intuition as old mouse/menu based systems because there simply aren't as many ways to give signposts to guide people around.
I'd argue that there are some aspects of the iPhone UI that aren't particularly discoverable, such as cut-paste. In the end, many people will have to go look them up. Once you know them, they fall into the "easily remembered" category, and might even seem "intuitive" after you've used them a few times.
On a separate note, if the cut-paste feature keeps kicking in where it's not welcome, I'd say that's a mark against its "forgivingness" score. But that's a different problem altogether.
The reason you need the decimal datatype is not because "small numbers get lost in the noise." It's because paper-driven accounting was always done in decimal, and so to keep the numbers matching, the computer needs to round in the same way someone doing it on pencil and paper would do it. It's about compatible rounding and representation, not the size of "ulp" (Units of the Last Place) on any given calculation. A 32-bit decimal float is less precise and has less dynamic range than a 32-bit binary float. But, arithmetic with the decimal float will match the hand arithmetic and the binary one won't, since the inputs come pre-rounded to convenient boundaries in the base-10 world.
Anyway, small numbers do get lost in the noise with floating point if you ever add or subtract them from large numbers.
I can't see why someone would parasitically intertwine two independent pieces of data to one another, i.e. make an audio stream that doesn't make sense without a video stream, or vice versa, in a strict data sense.
I could, if it were some esoteric format. (For example, I've considered doing something like that to log data out of my Intellivision emulator, since it happens to be easier to do that way for my purposes, and therefore it is in no sense general purpose. Esoteric is a perfect label for it.) But, if it's some esoteric format, the label "esoteric" applies to both the audio and the video together, since they're clearly joined at the hip. In that situation, what are the odds you can decode one but not both?
For more traditional codecs, though, you're exactly right. Each one brings its own framing/chunking requirements so it makes no sense to store one's metadata in the other.
I said "Older drivers tend to drive more slowly", not "All older drivers drive more slowly." The trend is certainly real. I only stated a property of the center of the curve, not the breadth of the curve. In fact, all that matters are the number of people that are at the far end of the curve. If the curve shifts with age, then it can push more people into that "far end" zone.
Before I get to that, though, perhaps it'd help to consider a different example: Older people tend to have weaker bones. That explains why hip-fractures are concentrated among older folks. Does that mean all (or even most) old folks have weak bones and will suffer hip fracture? Heck no! But, if you averaged across the population, you'd find that, on average, their bones were weaker and their risk of a hip fracture was higher than the population as a whole.
Getting back to the undue acceleration: Only a fraction of a fraction of Toyotas exhibit this phenomenon. If it's triggered by a certain set of behaviors (such as "crotchety old person foot") that may only be exhibited by 0.01% of older people and 0.001% of everyone else, then that would be enough to explain why older people are more highly represented than any other group.
Not only that, but also it assumes that the only reason there's a correlation with age is that the likelihood of driver error increases with age.
Older drivers also tend to drive more slowly, accelerate more slowly and deliberately, and are more likely to give "noisy" inputs to the pedals, since their motor control isn't what it used to be. If there's a particular controller failure that's triggered by a "noisy" input (ie. lots of small variations at a fairly high frequency compared to the real desired control input), then it seems reasonable that the elderly might be over-represented.
In other words, let's all step away from the Jump To Conclusions mat.
I think we're saying the same thing in different words. I think it'll be clearer if I add a second term: The complexity per project is O((N/M)^2) where N is the number of people and M is the number of projects.
Since they scaled the number of projects to match the number of people, in my mind this is analogous to reducing "N" in what has generally been described as an O(N^2) problem. Your point is that if M is fixed, then it effectively becomes a "constant factor." That's true, but it was clear that they chose M to be close to N, so that N/M remains small, so it's not clear to me we should think of M as fixed. Rather, it's a variable that they explicitly chose to control.
Actually, they directly attacked "N". If you poured 40 people onto one project such that they all had to coordinate, you'd have 40*39/2 = 780 cross connections. (This is where the O(N^2) comes from.) Instead, they poured 40 people onto 40 more-or-less separate projects. That's more like 40 instances of an N of 1.
There is a legit package named PDF Suite. It's unclear whether that installation was legit or not. If "PDFs stopped working," it's entirely likely that the trial period for the legit software expired. No idea. I wasn't weighing in on either side of that.
The problem as stated in this article's question is almost something of a fools errand: "I have a connection to the Internet that at best can give me benign but worthless stuff, and can give me unbounded amounts of virulent crap. I can't use this connection to download anything useful or helpful, nor can I bring anything with me that's useful and helpful. How do I avoid the crap?"
Perhaps I overstate it a bit, but not by too much, I don't think.
Well, if it was benign software, then maybe the free trial ended? Or, if it really did have some malware in it, maybe it was a "cracked" version, with extra Russian Hacker Goodness?
Right. My point is that I've seen a number of references claim that JPEG is supposed to store "linear light" data due to the statement "gamma = 1.0" in the JFIF spec, when really what JFIF means is that JPEG files deal with display-ready data that's already been gamma corrected.
Poynton's Gamma FAQ is pretty cool, BTW, and highlights a lot of the issues that arise with trying to discuss gamma, including folks throwing a lot of imprecise language around muddying the waters. His companion Color FAQ shows where a coding format such as JPEG is supposed to fit in item #27, and specifically in this diagram. JPEG provides the equivalent of the four blocks at the right (color-diff encode, subsampling, interpolation, color-diff decode). The input and output of JPEG is already in the non-linear domain.
That doesn't stop people from getting confused by the "gamma = 1.0" statement in the JFIF spec. For example this page makes the (incorrect) statement "The JFIF file standard (that uses JPEG compression) specifies that the image to be encoded must have a gamma of 1.0 (i.e. a linear image - but not everyone obeys the rules)." There's a lot of confusion out there. It's a mess.
Are you sure about that? I think you're right, but it's confusing. Supposedly, JFIF files are intended to have a gamma of 1.0. (JFIF stands for JPEG File Interchange Format and is the official name for what's inside a.JPG file.) Anyway, quoting from the JFIF spec:
A number of color spaces can be used: grayscale, RGB and CMYK are all common in prepress. For internet use, the color space can also be YCbCr as defined by CAIRN 601 (256 levels). The RGB components calculated by linear conversion from YCbCr shall not be gamma corrected (gamma = 1.0).
Now, that's the sound bite that suggests JFIF actually deals with linear light. But, if you carefully read the actual JFIF 1.02 spec and compare it to other resources, what sounds like "linear light" really isn't, and JPEGs really do encode "display-ready" pixels that are gamma corrected.
In the JFIF spec, it says:
The color space to be used is YCbCr as defined by CCIR 601 (256 levels). The RGB components calculated by linear conversion from YCbCr shall not be gamma corrected (gamma = 1.0). If only one component is used, that component shall be Y.
So far, it jibes with that first resource. A little later, on page 4, the JFIF spec gives a series of transformation functions between YCbCr and RGB. Mark your page, and flip with me to compare this to the referenced CCIR 601. Wikipedia has a nice summary here, assuming you don't want to send off to the ITU in Geneva for a copy of CCIR 601.
The matrix that JFIF defines matches the non-scaling YPbPr matrix in the Wikipedia page. That makes sense: Rather than use the narrower [16, 235] range that CCIR 601 specifies for component video, JFIF does state that Y, Cb and Cr "are normalized so as to occupy the full 256 levels of an 8-bit binary encoding." And if you scroll down on the Wikipedia page, you'll see that they have the same matrix with JPEG-specific scale factors applied that match the JFIF spec.
But here's the kicker. Notice that the CCIR matrix uses R', G' and B'. The prime symbol means that the signal is not linear light! That is, the signal is gamma corrected and is intended to be displayed on a device with the corresponding gamma as-is with no further correction.
This interpretation is bolstered by Charles Poynton's Color FAQ which states plainly: "The prime symbols in this equation, and in those to follow, denote nonlinear components," and later states "Use prime symbols ( ' ) to denote all of your nonlinear components!" Interestingly, Poynton also notes "no practical image coding system employs linear colour differences."
So what does that really mean? It means that while the JFIF spec says "gamma = 1.0," what they really seem to have meant (and, what everyone seems to have done) is take data intended for direct display without further correction, and then encode it. The result is that no gamma correction needs to be applied to a decoded JFIF file before display, because it's already in display gamma.
At least, I think. But if you just skim the JFIF spec, you'd come away thinking it dealt with linear light.
When you figure out how to get a botnet to only DDoS itself and not clog our inboxes with spam, let me know. Otherwise, legions of morons getting their machines conscripted into zombie hordes of spam-churning, site crashing drones is everybody's problem.
I'll throw my hat in the ring for both Head First Design Patterns and the GoF Design Patterns book. Read Head First first, though, since the GoF book is a bit dry by comparison.
Err, not quite. They say they saw a 50% rise in the number of claims in the month following a new product release, and that overall 4 in 10 claims is suspicious. Let's suppose they normally get 1,000 claims a month. Then a new iPhone comes out. They're saying that during the following month they'll get 1,500 claims instead of the usual 1,000.
Of all the iPhone claims that come in, they're saying 40% of them (4 in 10) are deemed suspicious. So, using my math above, out of the 12,500 claims they get in a year (assuming my pulled-out-of-a-hat 1,000 per month, plus an extra 500 during Apple's product release month), 5,000 claims are suspicious and 7,500 are not.
I have no idea what their absolute number of claims is, mind you. I just picked some nice, round numbers to make the math easy to follow. They also don't state what their overall claim rate is relative to the number of policies. For example, do only 1% of customers make a claim? 10%? 50%?
The body of the article makes sense and seems consistent. Whatever copyeditor wrote its headline spaced it though, and wrote the wrong number.
In the bottom of the article, they say "four in ten", not "four in six," so whoever wrote the headline made the mistake. "Four in ten" sounds more plausible, since it's more akin to a percentage (ie. 40%). I'm guessing whoever wrote the headline spaced it and pulled the "six" from the "six blows from a hammer" anecdote.
Slashdot Mirror
Another fun one to trip people up: A car travels around a 1 mile track. It goes around the its first lap at 30 MPH. How fast does it need to go on its second lap to average 60 MPH?
I imagine you'd probably have to go with 1000 miles to get numbers in a usable range:
FWIW, most gas tanks seem to be sized around a 300 - 350 mile range for the expected city fuel economy of the car. So, 1000 miles gives you an idea of the "cost of 3 fill-ups."
Wait, didn't Apple already step on Cisco's trademarks before with the iPhone?
Six of one, half a dozen of the other...
You can new non-objects, and (with "placement new") you can malloc objects!
One things for sure, C and C++ code can never truly be freed. Have you ever tried that on a function pointer?
It's not difficult at all. But it's only truly "obvious" in retrospect.
When my wife got her iPhone, I had to tell her how half the UI pieces worked, since she wasn't getting very far straight out of the box. Features such as "pinch to zoom", etc. are only obvious in retrospect. I only knew about these details because I read about them on Slashdot or articles linked from here. When I borrowed a friend's iPhone for a minute, I had to ask how to cut/paste, since I didn't actually know and I wasn't sure what to do.
Good UIs are highly discoverable and forgiving, and once learned, easily remembered. The best UIs do this to the point of being mistaken as "intuitive", but that's really a misnomer. For example, why, prior to ever seeing an iPhone, would my intuition tell me "pinch to zoom in/out" is the way to go? But once you've done it, you develop that association fairly quickly and then and only then it feels natural. To be truly intuitive, that means you should be able to figure it out driven only on intuition and things you've seen before alone. If it's only "intuitive" after you've seen it once, it's not intuitive.
A feature might be discoverable, though, and it's good to make the discovery process as intuitive as possible. For example, with the pull down menus of yore, your intuition might say "Oh, that's probably under the File menu" or the like, and if the UI designers have done a good job with their consistency, then it will be easy to develop that sort of intuition. Small touch screens on portable don't offer as many opportunities to develop that sort of intuition as old mouse/menu based systems because there simply aren't as many ways to give signposts to guide people around.
I'd argue that there are some aspects of the iPhone UI that aren't particularly discoverable, such as cut-paste. In the end, many people will have to go look them up. Once you know them, they fall into the "easily remembered" category, and might even seem "intuitive" after you've used them a few times.
On a separate note, if the cut-paste feature keeps kicking in where it's not welcome, I'd say that's a mark against its "forgivingness" score. But that's a different problem altogether.
The reason you need the decimal datatype is not because "small numbers get lost in the noise." It's because paper-driven accounting was always done in decimal, and so to keep the numbers matching, the computer needs to round in the same way someone doing it on pencil and paper would do it. It's about compatible rounding and representation, not the size of "ulp" (Units of the Last Place) on any given calculation. A 32-bit decimal float is less precise and has less dynamic range than a 32-bit binary float. But, arithmetic with the decimal float will match the hand arithmetic and the binary one won't, since the inputs come pre-rounded to convenient boundaries in the base-10 world.
Anyway, small numbers do get lost in the noise with floating point if you ever add or subtract them from large numbers.
I could, if it were some esoteric format. (For example, I've considered doing something like that to log data out of my Intellivision emulator, since it happens to be easier to do that way for my purposes, and therefore it is in no sense general purpose. Esoteric is a perfect label for it.) But, if it's some esoteric format, the label "esoteric" applies to both the audio and the video together, since they're clearly joined at the hip. In that situation, what are the odds you can decode one but not both?
For more traditional codecs, though, you're exactly right. Each one brings its own framing/chunking requirements so it makes no sense to store one's metadata in the other.
Yeah, full size picture books are much better than small collages, that way you get to see the detail in addition to the big picture.
Barf: I know we need the money, but...
Lone Starr: Listen! We're not just doing this for money!
Barf: [Barf looks at him, raises his ears]
Lone Starr: We're doing it for a S**T LOAD of money!
I remember reading somewhere that the theoretic highest scoring play in North American Scrabble is "OXYPHENBUTAZONE" across 3 triples. Yipe.
I said "Older drivers tend to drive more slowly", not "All older drivers drive more slowly." The trend is certainly real. I only stated a property of the center of the curve, not the breadth of the curve. In fact, all that matters are the number of people that are at the far end of the curve. If the curve shifts with age, then it can push more people into that "far end" zone.
Before I get to that, though, perhaps it'd help to consider a different example: Older people tend to have weaker bones. That explains why hip-fractures are concentrated among older folks. Does that mean all (or even most) old folks have weak bones and will suffer hip fracture? Heck no! But, if you averaged across the population, you'd find that, on average, their bones were weaker and their risk of a hip fracture was higher than the population as a whole.
Getting back to the undue acceleration: Only a fraction of a fraction of Toyotas exhibit this phenomenon. If it's triggered by a certain set of behaviors (such as "crotchety old person foot") that may only be exhibited by 0.01% of older people and 0.001% of everyone else, then that would be enough to explain why older people are more highly represented than any other group.
Not only that, but also it assumes that the only reason there's a correlation with age is that the likelihood of driver error increases with age.
Older drivers also tend to drive more slowly, accelerate more slowly and deliberately, and are more likely to give "noisy" inputs to the pedals, since their motor control isn't what it used to be. If there's a particular controller failure that's triggered by a "noisy" input (ie. lots of small variations at a fairly high frequency compared to the real desired control input), then it seems reasonable that the elderly might be over-represented.
In other words, let's all step away from the Jump To Conclusions mat.
I think we're saying the same thing in different words. I think it'll be clearer if I add a second term: The complexity per project is O((N/M)^2) where N is the number of people and M is the number of projects.
Since they scaled the number of projects to match the number of people, in my mind this is analogous to reducing "N" in what has generally been described as an O(N^2) problem. Your point is that if M is fixed, then it effectively becomes a "constant factor." That's true, but it was clear that they chose M to be close to N, so that N/M remains small, so it's not clear to me we should think of M as fixed. Rather, it's a variable that they explicitly chose to control.
Actually, they directly attacked "N". If you poured 40 people onto one project such that they all had to coordinate, you'd have 40*39/2 = 780 cross connections. (This is where the O(N^2) comes from.) Instead, they poured 40 people onto 40 more-or-less separate projects. That's more like 40 instances of an N of 1.
There is a legit package named PDF Suite. It's unclear whether that installation was legit or not. If "PDFs stopped working," it's entirely likely that the trial period for the legit software expired. No idea. I wasn't weighing in on either side of that.
The problem as stated in this article's question is almost something of a fools errand: "I have a connection to the Internet that at best can give me benign but worthless stuff, and can give me unbounded amounts of virulent crap. I can't use this connection to download anything useful or helpful, nor can I bring anything with me that's useful and helpful. How do I avoid the crap?"
Perhaps I overstate it a bit, but not by too much, I don't think.
Well, if it was benign software, then maybe the free trial ended? Or, if it really did have some malware in it, maybe it was a "cracked" version, with extra Russian Hacker Goodness?
Right. My point is that I've seen a number of references claim that JPEG is supposed to store "linear light" data due to the statement "gamma = 1.0" in the JFIF spec, when really what JFIF means is that JPEG files deal with display-ready data that's already been gamma corrected.
Poynton's Gamma FAQ is pretty cool, BTW, and highlights a lot of the issues that arise with trying to discuss gamma, including folks throwing a lot of imprecise language around muddying the waters. His companion Color FAQ shows where a coding format such as JPEG is supposed to fit in item #27, and specifically in this diagram. JPEG provides the equivalent of the four blocks at the right (color-diff encode, subsampling, interpolation, color-diff decode). The input and output of JPEG is already in the non-linear domain.
That doesn't stop people from getting confused by the "gamma = 1.0" statement in the JFIF spec. For example this page makes the (incorrect) statement "The JFIF file standard (that uses JPEG compression) specifies that the image to be encoded must have a gamma of 1.0 (i.e. a linear image - but not everyone obeys the rules)." There's a lot of confusion out there. It's a mess.
Are you sure about that? I think you're right, but it's confusing. Supposedly, JFIF files are intended to have a gamma of 1.0. (JFIF stands for JPEG File Interchange Format and is the official name for what's inside a .JPG file.) Anyway, quoting from the JFIF spec:
Now, that's the sound bite that suggests JFIF actually deals with linear light. But, if you carefully read the actual JFIF 1.02 spec and compare it to other resources, what sounds like "linear light" really isn't, and JPEGs really do encode "display-ready" pixels that are gamma corrected.
In the JFIF spec, it says:
So far, it jibes with that first resource. A little later, on page 4, the JFIF spec gives a series of transformation functions between YCbCr and RGB. Mark your page, and flip with me to compare this to the referenced CCIR 601. Wikipedia has a nice summary here, assuming you don't want to send off to the ITU in Geneva for a copy of CCIR 601.
The matrix that JFIF defines matches the non-scaling YPbPr matrix in the Wikipedia page. That makes sense: Rather than use the narrower [16, 235] range that CCIR 601 specifies for component video, JFIF does state that Y, Cb and Cr "are normalized so as to occupy the full 256 levels of an 8-bit binary encoding." And if you scroll down on the Wikipedia page, you'll see that they have the same matrix with JPEG-specific scale factors applied that match the JFIF spec.
But here's the kicker. Notice that the CCIR matrix uses R', G' and B'. The prime symbol means that the signal is not linear light! That is, the signal is gamma corrected and is intended to be displayed on a device with the corresponding gamma as-is with no further correction.
This interpretation is bolstered by Charles Poynton's Color FAQ which states plainly: "The prime symbols in this equation, and in those to follow, denote nonlinear components," and later states "Use prime symbols ( ' ) to denote all of your nonlinear components!" Interestingly, Poynton also notes "no practical image coding system employs linear colour differences."
So what does that really mean? It means that while the JFIF spec says "gamma = 1.0," what they really seem to have meant (and, what everyone seems to have done) is take data intended for direct display without further correction, and then encode it. The result is that no gamma correction needs to be applied to a decoded JFIF file before display, because it's already in display gamma.
At least, I think. But if you just skim the JFIF spec, you'd come away thinking it dealt with linear light.
What about Falcon 7?
When you figure out how to get a botnet to only DDoS itself and not clog our inboxes with spam, let me know. Otherwise, legions of morons getting their machines conscripted into zombie hordes of spam-churning, site crashing drones is everybody's problem.
I'll throw my hat in the ring for both Head First Design Patterns and the GoF Design Patterns book. Read Head First first, though, since the GoF book is a bit dry by comparison.
I'm waiting for these SVGA resolution, focus free projectors before I jump on the bandwagon.
Yeah, about the only way you could would be to break the proton into quarks and such, much like the LHC would. Hence my original comment. :-)
Err, not quite. They say they saw a 50% rise in the number of claims in the month following a new product release, and that overall 4 in 10 claims is suspicious. Let's suppose they normally get 1,000 claims a month. Then a new iPhone comes out. They're saying that during the following month they'll get 1,500 claims instead of the usual 1,000.
Of all the iPhone claims that come in, they're saying 40% of them (4 in 10) are deemed suspicious. So, using my math above, out of the 12,500 claims they get in a year (assuming my pulled-out-of-a-hat 1,000 per month, plus an extra 500 during Apple's product release month), 5,000 claims are suspicious and 7,500 are not.
I have no idea what their absolute number of claims is, mind you. I just picked some nice, round numbers to make the math easy to follow. They also don't state what their overall claim rate is relative to the number of policies. For example, do only 1% of customers make a claim? 10%? 50%?
The body of the article makes sense and seems consistent. Whatever copyeditor wrote its headline spaced it though, and wrote the wrong number.
In the bottom of the article, they say "four in ten", not "four in six," so whoever wrote the headline made the mistake. "Four in ten" sounds more plausible, since it's more akin to a percentage (ie. 40%). I'm guessing whoever wrote the headline spaced it and pulled the "six" from the "six blows from a hammer" anecdote.