The main problem is with what economists call externalities. Waste byproducts, pollution, resource depletion, etc. are all negative externalities that aren't immediately reflected in the cost of a good or service. Policy decisions, though, such as pollution regulation, manufacturer takeback requirements, and so on can internalize those costs in the final selling price of a good or service.
This is where regulation meets the marketplace, and how proper regulations and policies can work together with market forces to drive sustainability. But, it does require forces outside the market (such as government regulation) to internalize those costs so that they get accounted for up front.
For example, I actually would be in favor of increased fuel taxes, with the money allocated directly to greenhouse gas abatement programs, whether it's planting tree farms or sequestering carbon by some other means, or converting power plants away from coal.
I'd love to see a benchmark superimposed on Kraken which measures browser response time in milliseconds over the course of a Kraken run. You'd then get a composite score:
Kraken run time
Mean response time
Max response time
When I made the mistake of clicking "run" on Kraken a moment ago, I'd say anecdotally, that "mean" comes in around 5 seconds and "max" around 10 or 15. I didn't let Kraken finish. This is with Firefox 3.6.9 under Windows XP on a 2.2GHz Core2 Duo.
If they use this for scientific work (which I imagine they might), something tells me they won't have any Bayer matrix on it, and will instead do multiple shoots with different whole-image filters, to avoid artifacts due to demosaicing.
I was thinking the exact same thing. With a few choice search and replace steps, this could almost be a review for anything! I gather it has something to do with education, given the references to educators and students.
Looking at this from the perspective of $PROFESSION, I can see this publication being used in two main ways. $PROFESSIONALS can dip in and out of the publication to cement their understanding and it can also be used in formulating support for $USERS who are using $PRODUCT for the first time. For both of these purposes, the authors' previous experience of writing instructional text for technology shines through, with flowing informal writing that is easy to digest and a logical stepped approach to introducing each of the key features. Use of screenshots is intelligently done and you are provided with questions to test your understanding within every chapter. I particularly liked the 'Have a go hero' sections provided throughout the book, which are designed to encourage deeper investigation by the reader.
Just a wee bit of background would have made the review more relevant, and less like this..
You know, if they up it to just a bit over 4 billion unique 32-bit keys, say around 4,294,967,296 or so, I think I could sort them rather efficiently, as long as they weren't attached to any payload.;-)
Erm... my understanding of Briefs is that it still requires you to make a native-built app. It is emphatically not a framework. Rather, it lets you try on different renderings of things that you could do within Apple's framework in a simple do-nothing environment. A bug in Briefs is highly unlikely to propagate into an app, since it appears mainly to be a "preview app" for UI decisions--a live white-board, if you will. From the description in TFA, it sounds like Briefs gives you a mechanism to quickly mock up new interfaces (within the constraints of what Apple's widgets let you do) and try it on to check out the feel, even though you can't actually hook it to an application.
Once you've got the fit and finish of the user interaction down, it sounds like it's still up to you to program your actual app to actually do that. That is, because Briefs is not a framework, you can't hang an application off of it. You can only prototype look and feel. It's still up to you to implement it, and when you implement it, you'll be implementing it as a native built app.
Ok, so the page lists a 240M keys/sec sorting implementation for a quad-core Core i7, versus their 1G keys/sec for the GPU. How many processors were on that GPU? It's a 4x speedup end-to-end, sure, but it sure didn't scale linearly in the number of processors.
Computing tasks will always be a mix of truly serial vs. mostly serial but parallelizable with herculean effort vs. embarrassingly parallel (and all points in between). GPUs work on the embarrassingly parallel stuff with ease, and fall off as you get more serial. x86s, on the other hand, attack truly serial tasks with clock rate and mostly serial tasks with speculation and a bunch of extra hardware that hunts for every spec of available parallelism. Which type of processor does best depends on the problem you're trying to solve.
The heap is entirely in userspace, and the kernel is powerless to do anything about it.
Imagine some fun, idiotic code that allocated, say, 1 million 2048 byte records sequentially (2GB total), and then only freed the even-numbered records. (I'm oversimplifying a bit, but the principle holds.) Now you've leaked 1GB memory, but its spread over 2GB space.
The kernel only works in 4K chunks when paging. Each 4K page, though, has 2K of leaked data and 2K of free space. For all the subsequent non-leak allocations that fit in these holes, you effectively "amplify" the footprint due to the leaked data that shares the same 4K page. If you try to use 1GB of space for some actual work within that same process, the working set the kernel's VM will see will look more like 2GB if all the allocations fill the holes.
Sometimes that doesn't work out so well. If you have a fragmented heap with gaps between the leaked items that keep getting reused, it can lead to a lot of strange thrashing, since it effectively amplifies your working set size.
I think that may be one of the things that was happening to older Firefoxes (2.x when viewing gmail, in particular)... not only did it leak memory, it leaked memory in a way such that the leak couldn't just stay in swap.
I never meant to imply that solar was free. But, once solar capacity is built out and the transmission lines are in place, solar has quite a lot of potential to be cheaper than fossil fuels, particularly if fossil fuels are made artificially more expensive through carbon taxes. I don't have to mine or drill for solar power. I don't have ships, train cars and semis carting solar power all over the country. So, as solar capacity comes online, the overall cost of energy may drop, not because solar doesn't cost anything, but that it costs less than the alternatives.
Wait, are you saying Arnie's a better actor than Ronnie? Hmm... if you took the ratio of their talent, I think you'd have to apply L'Hopital's rule to figure out whether the ratio was above or below 1.;-)
That certainly keeps with the spirit of my original post. I did forget one word though: Storage. We need to capture, redistribute and *store* energy. Facilitating the carbon cycle in this way (using algae to create diesel/gasoline/kerosene, for example) also helps address the storage problem. Note that I say "carbon cycle:" This isn't the same as pumping carbon out of the ground and putting it in the air. The algae have to get carbon from somewhere before you get diesel/gasoline/kerosene.
Well, certainly expensive at first. If we keep building out capacity, though, so that we're collecting 2-3x what we currently use, price per unit will eventually come done.
'The EU is backing the construction of new electricity cables, known as inter-connectors, under the Mediterranean Sea to carry this renewable energy from North Africa to Europe. Some environmental groups have warned these cables could be used instead to import non-renewable electricity from coal- and gas-fired power stations in north Africa.' To this the energy minister replied, essentially, 'Good question, we'll get back to you on that.'
To quote Firesign Theatre, it's a "power so great, it can only be used for good or evil!"
All seriousness aside, we need better energy conduits from these arid, sun-soaked regions. There is an abundance of solar energy waiting to be tapped in our deserts. Many, many, many human ills could be easily tackled by abundant energy. Sure, 1% of the Sahara can power our current usage. That fails to account for the fact that use increases as cost decreases. I'm sure if we managed to capture a much larger fraction of it, we'd put it to many unforseen uses, such as food synthesis, carbon sequestration, and so on.
I think it's high time we started tapping seriously into the energy arriving at earth daily. There is no energy shortage. There is only an energy collection and redistribution shortage.
I'm sorry but clarifying in the second post doesn't explain a supposed initial understanding that there be only two laps. That was my question.
That's right. You misunderstood it the first time, and I can't change that. I didn't, however, change the problem I intended to state by clarifying what I meant. I only gave a more explicit description. Clarification gives you a second chance to understand what I meant by making what I meant more explicit, where what I meant remained fixed. Your understanding of what I meant is allowed--indeed expected--to change at that time. Just because it does doesn't mean I'm trying to change my problem statement on you.
If we're arguing that the way I stated it initially allowed you to misinterpret it, and that it was reasonable to misinterpret it the way you did prior to my clarification, then fine: You win. I needed to clarify it more so that everyone could understand it. You're the only person so far who seems to have needed it though.
I never intended to ask the question: "Given a first lap at speed X, at what speed would the driver have to drive an unknown number of subsequent laps to get to an average speed Y?" That problem statement doesn't boil down to a single answer. My intent from the beginning was for the reader to find the average speed across the first two laps.
Shall we agree to disagree?
Sure, why not. I'm not certain that my original intent is the subject of opinion, but ok.
Look around you at all the stuff that's already set up this way:
Temperatures: Whether you use Fahrenheit or Celsius, most temperatures humans encounter in their environment have 2 digits to the left of the decimal, only edging a bit into 3 digit territory. (Ok, a bit more so for Fahrenheit users in the desert.) We could have had a coarser or finer-grained temperature scale, but both Celsius and Fahrenheit settled on ranges with this property.
Car speeds: Unless you're in a metric country or breaking the law in a big way, your car's speed when moving is almost always a 2 digit number. And even in a metric country, you don't go very far above 100kph anyway.
Progress bars and other percents: Most percentages we encounter have 2 digits left of the decimal. Why don't we use 10ths (1 digit) or per mille (3 digits)?
Stock prices, as mentioned above
There is a notable counter-example: Heights. Rather than give people's height in inches (ie. I'm 74" tall), we tend to give feet and inches (6' 2").
Still, I think there's considerable value scaling the fuel economy range so that most numbers have 2 digits left of the decimal. One digit isn't enough--too many people will ignore the fraction--and three is too many, IMHO.
My original problem statement was: "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?" The intent was to find the average across the set of events mentioned in the problem (first lap, second lap). I later clarified in a follow-up to you "...average 60 MPH across both laps."
That's where.
And it's solvable in the sense that you can say, in a mathematically rigorous way, the requested average is unachievable. The point of the brain teaser is not to send the reader off on a fool's errand, but rather to highlight that one's gut feel/initial reaction ("Oh, 90MPH!") can be way, way off when dealing with rates rather than with consumed quantities (whether they be time intervals or fuel). I remember a math teacher using this exact example when introducing this notion in math class, for precisely this reason.
You missed my point entirely about the track length being a red herring. If I said the track is "X miles long" and didn't fill in a number, you can still work the problem. The key is that you are limited to two laps. The problem asks what speed the second lap has to be given the speed of the first lap and the desired average between the two laps.
Yes, you need to find the total travel time to work the problem correctly, but it's a strict function of the track length, and it cancels out in the end. All you need to know are: 2 laps total, speed of the first lap, desired average. From that, you can find the required speed of the second lap.
For example, suppose instead of 30 MPH, I said the first lap went at 45 MPH, and the track length was unknown. You could still work the problem, filling in 'x' for the unknown track length:
(x / 45) + (x / speed) = (2*x / 60)
Divide both sides by 'x' and you get:
(1 / 45) + (1 / speed) = (2 / 60)
The track length cancels out. It is a red herring. And if you finish working the math, you get:
Multiply both sides by 'speed': (speed / 45) + 1 = (speed / 30)
Multiply both sides by 90: 2 * speed + 90 = 3 * speed
Subtract (2*speed) from both sides: 90 = speed
Notice I worked the problem with no notion of a "time limit" and without knowledge of the track length.
Yes, I think those numbers are too small to be useful, for the same reason many companies do stock splits and reverse stock splits to keep the price in the 2-digit range, and people talk about how old their toddler is in months instead of fractional years. It's about keeping around 2 significant figures to the left of the decimal.
I think subconsciously most people only look closely at the digits to the left of the decimal. That "3.5" and "2.8" you mentioned will get turned into "3-ish" and "2-ish" to a casual glance. Thus, the average person casually comparing that to a car that gets 3.1 and 2.2 is likely to say "about the same." But if you said 35/28 vs. 31/22, I bet more people would zoom in on the second car getting much better highway mileage. "This one is almost 30, but that one's barely 20!"
The intended answer is "it can't be done" or "infinitely fast" (the two more or less meaning the same thing). The naive answer (the one most people will give if they aren't paying close enough attention) is "90 MPH." This is exactly the same math mistake as the fuel economy question in the article, just carried to the absolute limit. Imagine if I changed the question to be "Consider a car with a widely-variable fuel economy, such as a hybrid which switches between gasoline and electric. If my car gets 30 MPG during its first mile, what fuel economy would I need during my second mile to average 60 MPG across both miles?" It's exactly the same math with exactly the same pitfalls.
I'm not sure where you were going in the second and third paragraphs. There isn't a time limit per se. There's a limit on the number of laps. Ok, I could have been more explicit and said "average 60MPH across both laps," but I thought that was fairly obvious.
In fact, the problem works out the same regardless of the track size, which is why "time limit" doesn't have any direct bearing. I could have left the track size out of it and it doesn't change the math, because the travel time for one lap cancels out. Thus "1 mile track" was actually a red herring. You'd get the same result ("infinitely fast") with a 10 mile track or a 1,000,000,000 mile track.
Slashdot Mirror
The main problem is with what economists call externalities. Waste byproducts, pollution, resource depletion, etc. are all negative externalities that aren't immediately reflected in the cost of a good or service. Policy decisions, though, such as pollution regulation, manufacturer takeback requirements, and so on can internalize those costs in the final selling price of a good or service.
This is where regulation meets the marketplace, and how proper regulations and policies can work together with market forces to drive sustainability. But, it does require forces outside the market (such as government regulation) to internalize those costs so that they get accounted for up front.
For example, I actually would be in favor of increased fuel taxes, with the money allocated directly to greenhouse gas abatement programs, whether it's planting tree farms or sequestering carbon by some other means, or converting power plants away from coal.
I'd love to see a benchmark superimposed on Kraken which measures browser response time in milliseconds over the course of a Kraken run. You'd then get a composite score:
When I made the mistake of clicking "run" on Kraken a moment ago, I'd say anecdotally, that "mean" comes in around 5 seconds and "max" around 10 or 15. I didn't let Kraken finish. This is with Firefox 3.6.9 under Windows XP on a 2.2GHz Core2 Duo.
If they use this for scientific work (which I imagine they might), something tells me they won't have any Bayer matrix on it, and will instead do multiple shoots with different whole-image filters, to avoid artifacts due to demosaicing.
What about its competor, Lorem Ipsum 2.0? ;-)
I was thinking the exact same thing. With a few choice search and replace steps, this could almost be a review for anything! I gather it has something to do with education, given the references to educators and students.
Just a wee bit of background would have made the review more relevant, and less like this..
You know, if they up it to just a bit over 4 billion unique 32-bit keys, say around 4,294,967,296 or so, I think I could sort them rather efficiently, as long as they weren't attached to any payload. ;-)
Erm... my understanding of Briefs is that it still requires you to make a native-built app. It is emphatically not a framework. Rather, it lets you try on different renderings of things that you could do within Apple's framework in a simple do-nothing environment. A bug in Briefs is highly unlikely to propagate into an app, since it appears mainly to be a "preview app" for UI decisions--a live white-board, if you will. From the description in TFA, it sounds like Briefs gives you a mechanism to quickly mock up new interfaces (within the constraints of what Apple's widgets let you do) and try it on to check out the feel, even though you can't actually hook it to an application.
Once you've got the fit and finish of the user interaction down, it sounds like it's still up to you to program your actual app to actually do that. That is, because Briefs is not a framework, you can't hang an application off of it. You can only prototype look and feel. It's still up to you to implement it, and when you implement it, you'll be implementing it as a native built app.
Or did I miss something?
Ok, so the page lists a 240M keys/sec sorting implementation for a quad-core Core i7, versus their 1G keys/sec for the GPU. How many processors were on that GPU? It's a 4x speedup end-to-end, sure, but it sure didn't scale linearly in the number of processors.
Computing tasks will always be a mix of truly serial vs. mostly serial but parallelizable with herculean effort vs. embarrassingly parallel (and all points in between). GPUs work on the embarrassingly parallel stuff with ease, and fall off as you get more serial. x86s, on the other hand, attack truly serial tasks with clock rate and mostly serial tasks with speculation and a bunch of extra hardware that hunts for every spec of available parallelism. Which type of processor does best depends on the problem you're trying to solve.
The heap is entirely in userspace, and the kernel is powerless to do anything about it.
Imagine some fun, idiotic code that allocated, say, 1 million 2048 byte records sequentially (2GB total), and then only freed the even-numbered records. (I'm oversimplifying a bit, but the principle holds.) Now you've leaked 1GB memory, but its spread over 2GB space.
The kernel only works in 4K chunks when paging. Each 4K page, though, has 2K of leaked data and 2K of free space. For all the subsequent non-leak allocations that fit in these holes, you effectively "amplify" the footprint due to the leaked data that shares the same 4K page. If you try to use 1GB of space for some actual work within that same process, the working set the kernel's VM will see will look more like 2GB if all the allocations fill the holes.
Make sense?
Sometimes that doesn't work out so well. If you have a fragmented heap with gaps between the leaked items that keep getting reused, it can lead to a lot of strange thrashing, since it effectively amplifies your working set size.
I think that may be one of the things that was happening to older Firefoxes (2.x when viewing gmail, in particular)... not only did it leak memory, it leaked memory in a way such that the leak couldn't just stay in swap.
It might be, if, you know, you couldn't take the privacy filter back off the display when you do actually want to share your display.
Everyone keeps mentioning examples of how this is old news that aren't more than 10 or 15 years old. Try 25 years old.
Erm, that's an average of 66 clicks per user I'd imagine.
You mean, 403 is not forbidden?
I never meant to imply that solar was free. But, once solar capacity is built out and the transmission lines are in place, solar has quite a lot of potential to be cheaper than fossil fuels, particularly if fossil fuels are made artificially more expensive through carbon taxes. I don't have to mine or drill for solar power. I don't have ships, train cars and semis carting solar power all over the country. So, as solar capacity comes online, the overall cost of energy may drop, not because solar doesn't cost anything, but that it costs less than the alternatives.
Wait, are you saying Arnie's a better actor than Ronnie? Hmm... if you took the ratio of their talent, I think you'd have to apply L'Hopital's rule to figure out whether the ratio was above or below 1. ;-)
That certainly keeps with the spirit of my original post. I did forget one word though: Storage. We need to capture, redistribute and *store* energy. Facilitating the carbon cycle in this way (using algae to create diesel/gasoline/kerosene, for example) also helps address the storage problem. Note that I say "carbon cycle:" This isn't the same as pumping carbon out of the ground and putting it in the air. The algae have to get carbon from somewhere before you get diesel/gasoline/kerosene.
Well, certainly expensive at first. If we keep building out capacity, though, so that we're collecting 2-3x what we currently use, price per unit will eventually come done.
To quote Firesign Theatre, it's a "power so great, it can only be used for good or evil!"
All seriousness aside, we need better energy conduits from these arid, sun-soaked regions. There is an abundance of solar energy waiting to be tapped in our deserts. Many, many, many human ills could be easily tackled by abundant energy. Sure, 1% of the Sahara can power our current usage. That fails to account for the fact that use increases as cost decreases. I'm sure if we managed to capture a much larger fraction of it, we'd put it to many unforseen uses, such as food synthesis, carbon sequestration, and so on.
I think it's high time we started tapping seriously into the energy arriving at earth daily. There is no energy shortage. There is only an energy collection and redistribution shortage.
That's right. You misunderstood it the first time, and I can't change that. I didn't, however, change the problem I intended to state by clarifying what I meant. I only gave a more explicit description. Clarification gives you a second chance to understand what I meant by making what I meant more explicit, where what I meant remained fixed. Your understanding of what I meant is allowed--indeed expected--to change at that time. Just because it does doesn't mean I'm trying to change my problem statement on you.
If we're arguing that the way I stated it initially allowed you to misinterpret it, and that it was reasonable to misinterpret it the way you did prior to my clarification, then fine: You win. I needed to clarify it more so that everyone could understand it. You're the only person so far who seems to have needed it though.
I never intended to ask the question: "Given a first lap at speed X, at what speed would the driver have to drive an unknown number of subsequent laps to get to an average speed Y?" That problem statement doesn't boil down to a single answer. My intent from the beginning was for the reader to find the average speed across the first two laps.
Sure, why not. I'm not certain that my original intent is the subject of opinion, but ok.
Look around you at all the stuff that's already set up this way:
There is a notable counter-example: Heights. Rather than give people's height in inches (ie. I'm 74" tall), we tend to give feet and inches (6' 2").
Still, I think there's considerable value scaling the fuel economy range so that most numbers have 2 digits left of the decimal. One digit isn't enough--too many people will ignore the fraction--and three is too many, IMHO.
My original problem statement was: "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?" The intent was to find the average across the set of events mentioned in the problem (first lap, second lap). I later clarified in a follow-up to you "...average 60 MPH across both laps."
That's where.
And it's solvable in the sense that you can say, in a mathematically rigorous way, the requested average is unachievable. The point of the brain teaser is not to send the reader off on a fool's errand, but rather to highlight that one's gut feel/initial reaction ("Oh, 90MPH!") can be way, way off when dealing with rates rather than with consumed quantities (whether they be time intervals or fuel). I remember a math teacher using this exact example when introducing this notion in math class, for precisely this reason.
You missed my point entirely about the track length being a red herring. If I said the track is "X miles long" and didn't fill in a number, you can still work the problem. The key is that you are limited to two laps. The problem asks what speed the second lap has to be given the speed of the first lap and the desired average between the two laps.
Yes, you need to find the total travel time to work the problem correctly, but it's a strict function of the track length, and it cancels out in the end. All you need to know are: 2 laps total, speed of the first lap, desired average. From that, you can find the required speed of the second lap.
For example, suppose instead of 30 MPH, I said the first lap went at 45 MPH, and the track length was unknown. You could still work the problem, filling in 'x' for the unknown track length:
(x / 45) + (x / speed) = (2*x / 60)
Divide both sides by 'x' and you get:
(1 / 45) + (1 / speed) = (2 / 60)
The track length cancels out. It is a red herring. And if you finish working the math, you get:
Notice I worked the problem with no notion of a "time limit" and without knowledge of the track length.
Yes, I think those numbers are too small to be useful, for the same reason many companies do stock splits and reverse stock splits to keep the price in the 2-digit range, and people talk about how old their toddler is in months instead of fractional years. It's about keeping around 2 significant figures to the left of the decimal.
I think subconsciously most people only look closely at the digits to the left of the decimal. That "3.5" and "2.8" you mentioned will get turned into "3-ish" and "2-ish" to a casual glance. Thus, the average person casually comparing that to a car that gets 3.1 and 2.2 is likely to say "about the same." But if you said 35/28 vs. 31/22, I bet more people would zoom in on the second car getting much better highway mileage. "This one is almost 30, but that one's barely 20!"
The intended answer is "it can't be done" or "infinitely fast" (the two more or less meaning the same thing). The naive answer (the one most people will give if they aren't paying close enough attention) is "90 MPH." This is exactly the same math mistake as the fuel economy question in the article, just carried to the absolute limit. Imagine if I changed the question to be "Consider a car with a widely-variable fuel economy, such as a hybrid which switches between gasoline and electric. If my car gets 30 MPG during its first mile, what fuel economy would I need during my second mile to average 60 MPG across both miles?" It's exactly the same math with exactly the same pitfalls.
I'm not sure where you were going in the second and third paragraphs. There isn't a time limit per se. There's a limit on the number of laps. Ok, I could have been more explicit and said "average 60MPH across both laps," but I thought that was fairly obvious.
In fact, the problem works out the same regardless of the track size, which is why "time limit" doesn't have any direct bearing. I could have left the track size out of it and it doesn't change the math, because the travel time for one lap cancels out. Thus "1 mile track" was actually a red herring. You'd get the same result ("infinitely fast") with a 10 mile track or a 1,000,000,000 mile track.