But this isn't generally what's being portrayed to the public at large by politicians all over the world (event most Green political parties aren't being honest with the public because no-one likes Debbie Downers, even if they're really more like Cassandra).
People (mainly politicians and the business elite) carry on like the Paris climate agreement is a really strong step towards preventing climate change and we just need to ramp things up a bit more. But we're actually really really far away from having solved it.
If we don't allow for any (serious / industrial-scale) carbon sequestration, then all human carbon emissions on the planet need to be 0 by 2020. In other words carbon emissions in 2018 need to be half this years, then 2019 need to be half of that, and 2020 needs to be 0.
Even if we take a geoengineering approach, eg make artificial clouds to increase albedo and reflect heat, we're still pumping more and more CO2 into the air, which mostly ends up in the oceans, leading to acidification and destruction of aquatic ecosystems. A large number of people in the world have seafood as one of their primary nutrition sources, and many fish stocks are already under threat from overfishing.
In current carbon accounting, it is deemed that once a tree is harvested, all of its carbon is released at that moment. The thinking being that if it's made into paper, it will likely be discarded and begin decomposing within 5 years anyway. If it's toilet paper it may be much less time than that. Obviously furniture like tables last many more years than that, but ultimately 99% of tables sold in shops today will end up discarded within 100 years, probably burnt for fuel or just damaged and thrown in a dump somewhere.
So the only way out of this that would make the carbon accountants happy, is if the trees were harvested and then specifically entombed somewhere to sequester the carbon, like in an old salt mine or something.
But it won't take very long until all of the salt mines are filled with wood, so then what do you do?
When those debugging techniques prevent the code from properly responding to hardware interrupts in time, to the extent that the code locks up and doesn't operate at all, yes.
Lets expose all of our priceless artefacts to radiation from deep space, to ensure that no human can ever stand in close proximity to them ever again.
Really this idea is ludicrous and a complete non-starter. The point of museums is to store those artifacts for future generations to study and learn from. Pretty difficult to study artifacts that are in orbit, and irradiated.
SC isn't a full-knowledge game. The AI has to spend resources in order to scout the enemy - resources that could be used on army production. So you have the extreme of an AI that spends all of it's money on scouts, and has no money left for an army. Or an AI that spends all of its money on army, and doesn't do any scouting.
In top-level competitive play, scouting is one of the make-or-break points in the game. You occasionally see a game where a player managers to kill the opponents first scout before that scout has been able to see enough of the enemy's technology. That player is now in a very very difficult spot - do they try and 'guess' what the opponent is doing, do they spend more money on another scout and get late information?
If the AI does scouting and sees building A, but the scout is killed before it can see building B, does it assume building B must exist, because that's the "most likely" build order? Lilke 70% of the time you see building A, you will also see building B, so just assume building B was there even though you didn't see it? If you make that hard assumption, 30% of the time you'll be wrong. A human may be able to pick up on contextual clues (the map, the opponents playing history on that map, their play style, what else they did in the tournament) to help make the right decision, but an AI player only has the data it saw with its probe to work off.
If the AI has a set of specific build orders that it specifically knows about, what does it do when it discovers a situation outside of those known build orders? If the human opponent knows that the AI is programmed only with specific build orders, then they can deliberately fake it out. A simple example is a "proxy barracks". Say you normally build a barracks (to produce basic troops) at time 3 minutes. AI scouts your base, doesn't see any sign of barracks or anything else - what does it do? Assume the player is not going to build any army at all? Turns out the player is actually building the barracks right next to the AI's base, but the AI incorrectly assumes there is no barracks at all, because they didn't see one. 90 seconds later, 3 marines turn up at the AI base, how does it react?
Here's some general thoughts on what makes SC difficult for an AI.
Starcraft has areas of focus called 'macro' and 'micro'. Macro is base building, selecting which tech tree to advance down, upgrading, building your economy. Micro is controlling small groups or individual units and their position on the map and how they engage with enemy units. For a very rough idea, alternative terms would be macro = strategy, micro = tactics.
Someone who is excellent at macro can be destroyed by someone who is lousy at macro and excellent at micro, and vice versa. The top players are excellent at both macro and micro.
Scouting what your opponent is doing is a bit part of both your macro and micro strategies but in different ways. If you see the enemy has built unit factory X, then you better counter it by building Y (macro). If it's in map location Z, then you better make sure you get your units to position A to head them off (micro).
There are 3 races in SC so 6 possible match-ups include the 'mirror' matchups. If both players are random, then each player must scout their enemy to initially learn their race. Then there are known build-orders, so if you scout your enemy at time 2 minutes, and see X and Y, then you can conclude they are (probably) using strategy A. But if you get that exact same set of information at time 4 minutes, then concluding they are using strategy A may be a mistake.
Humans know these build orders (like expert players memorising important chess gambits), but the AI likely doesn't, so has to brute force everything. Brute-forcing is possible in chess, and thought impossible in Go. So Starcraft is an extension in this same area.
Lol, as if "power users" make up any more than 0.1% of the user base. Similarly I'm sure that 90% of developers don't *need* what you're pining for either.
The US Military has already gotten that beat, too. With rectal feeding (google it), they put food directly into your ass! So you don't even have to put up with the hassle of chewing and swallowing - even more convenient than what those soylent people are doing.
Lots of people have responded suggesting various tools or whatnot. It is quite likely that you already have a good (perhaps not the best) tool for the job, and what you actually need to do is change the processes that humans are following.
The best way to approach this is to use the "5 whys" approach, where you state the problem (or group of problems) and ask "why" 5 times to try and work out the root causes, then address them.
Eg, Problem: We have too many duplicate error reports. Why? Because testers don't know about existing bugs before raising new ones. Why? Because the testers don't search for existing issues on the backlog before raising new ones. Why? Because they haven't been trained properly.
Other possible answers for the above train may be "our backlog doesn't make searching easy" or "testers don't have a consistent way of recording issues so its difficult to find the same issue raised by different testers".
Anyway, you can do the 5 why's process yourself, but some potential root causes and responses you can take:
You have too many bugs in your software, so it's going to be hard to get on top of them no matter what processes you put in place.
* Perhaps there are developers in your team who don't have a good understanding of the system and generate bad code -> training or peer-programming might help. * Perhaps your fundamental architecture needs to be refactored / improved / better documented to reduce the incidence of bugs. * Perhaps your team has too much work load or is under too much pressure to get features out on time that you don't have adequate time to address your bugs, and they're building up into an unmanageable pile. * Perhaps people on your team don't think it's their responsibility to fix bugs in their own code or they don't think it's 'fun' - someone else's job - and other people aren't proficient in that area of the code and so take longer to fix the bugs, or create new bugs in the process. * Perhaps your team is just more interested in pushing through to 'new' things, and don't take the time to clean up bugs as they go, building new code on top of bad.
Other problems might arise from the testers.
* Perhaps you have lots of different people testing the software and raising bugs (instead of a core team of a few testers who become intimately familiar with the software), and they all have their own writing style or way of recording bugs, making it hard for any tester to know if any other tester has already raised a bug. * Perhaps your testers just don't talk to each other - "oh yeah, I saw something like that 2 weeks ago...". * Perhaps your testers don't search through the existing issues before raising new ones - perhaps because the tool doesn't support it well, or simply no-ones told them its a good idea to do. * Perhaps your software doesn't have a good way of reporting bugs - if your software crashes, having consistent and common output to allow testers to identify "crash X is the same as crash Y" means they don't need to raise a second bug to report Y, instead they could just find the report for crash X (by searching for unique output in the crash) and add their new incident there.
Another thing to consider is that maybe you just need to groom the backlog from time to time. Go through and look at *all* the bugs in one sitting, and you might quickly find duplicates that you can merge/link together. You might also find that there's a bunch of bugs that you know you'll just "never" fix because they aren't important, so these could be closed or moved elsewhere to minimise the noise in the system, letting you focus just on the important stuff that matters.
Don't expect that there is going to be a 'quick fix' from adopting a new tool. It is very likely that some of the above human processes are contributing to your unmanageable backlog, and moving to a new tool won't markedly change your performance.
Slashdot Mirror
The single best thing you can do to help prevent climate change (that doesn't involve murder / suicide) is to not have children.
But this isn't generally what's being portrayed to the public at large by politicians all over the world (event most Green political parties aren't being honest with the public because no-one likes Debbie Downers, even if they're really more like Cassandra).
People (mainly politicians and the business elite) carry on like the Paris climate agreement is a really strong step towards preventing climate change and we just need to ramp things up a bit more. But we're actually really really far away from having solved it.
If we don't allow for any (serious / industrial-scale) carbon sequestration, then all human carbon emissions on the planet need to be 0 by 2020. In other words carbon emissions in 2018 need to be half this years, then 2019 need to be half of that, and 2020 needs to be 0.
Even if we take a geoengineering approach, eg make artificial clouds to increase albedo and reflect heat, we're still pumping more and more CO2 into the air, which mostly ends up in the oceans, leading to acidification and destruction of aquatic ecosystems. A large number of people in the world have seafood as one of their primary nutrition sources, and many fish stocks are already under threat from overfishing.
In current carbon accounting, it is deemed that once a tree is harvested, all of its carbon is released at that moment. The thinking being that if it's made into paper, it will likely be discarded and begin decomposing within 5 years anyway. If it's toilet paper it may be much less time than that. Obviously furniture like tables last many more years than that, but ultimately 99% of tables sold in shops today will end up discarded within 100 years, probably burnt for fuel or just damaged and thrown in a dump somewhere.
So the only way out of this that would make the carbon accountants happy, is if the trees were harvested and then specifically entombed somewhere to sequester the carbon, like in an old salt mine or something.
But it won't take very long until all of the salt mines are filled with wood, so then what do you do?
When those debugging techniques prevent the code from properly responding to hardware interrupts in time, to the extent that the code locks up and doesn't operate at all, yes.
Valgrind drastically reduces the performance of the software, so isn't practical for critical code that needs to execute quickly.
Lets expose all of our priceless artefacts to radiation from deep space, to ensure that no human can ever stand in close proximity to them ever again.
Really this idea is ludicrous and a complete non-starter. The point of museums is to store those artifacts for future generations to study and learn from. Pretty difficult to study artifacts that are in orbit, and irradiated.
Season 3 of enterprise is relatively good, although there are a few bad filler episodes, including the abysmal "North star".
It was cancelled in season 4.
Nothing so direct, but wanting to roll back healthcare from millions of people is substantially the same thing.
But that's not "the best move", that's the point.
SC isn't a full-knowledge game. The AI has to spend resources in order to scout the enemy - resources that could be used on army production. So you have the extreme of an AI that spends all of it's money on scouts, and has no money left for an army. Or an AI that spends all of its money on army, and doesn't do any scouting.
In top-level competitive play, scouting is one of the make-or-break points in the game. You occasionally see a game where a player managers to kill the opponents first scout before that scout has been able to see enough of the enemy's technology. That player is now in a very very difficult spot - do they try and 'guess' what the opponent is doing, do they spend more money on another scout and get late information?
If the AI does scouting and sees building A, but the scout is killed before it can see building B, does it assume building B must exist, because that's the "most likely" build order? Lilke 70% of the time you see building A, you will also see building B, so just assume building B was there even though you didn't see it? If you make that hard assumption, 30% of the time you'll be wrong. A human may be able to pick up on contextual clues (the map, the opponents playing history on that map, their play style, what else they did in the tournament) to help make the right decision, but an AI player only has the data it saw with its probe to work off.
If the AI has a set of specific build orders that it specifically knows about, what does it do when it discovers a situation outside of those known build orders? If the human opponent knows that the AI is programmed only with specific build orders, then they can deliberately fake it out. A simple example is a "proxy barracks". Say you normally build a barracks (to produce basic troops) at time 3 minutes. AI scouts your base, doesn't see any sign of barracks or anything else - what does it do? Assume the player is not going to build any army at all? Turns out the player is actually building the barracks right next to the AI's base, but the AI incorrectly assumes there is no barracks at all, because they didn't see one. 90 seconds later, 3 marines turn up at the AI base, how does it react?
See also, this comment: https://games.slashdot.org/com...
6 combinations, 9 permutations.
Home arena aside, Packers vs Raiders is the same game as Raiders vs Packers.
big* part of both
Here's some general thoughts on what makes SC difficult for an AI.
Starcraft has areas of focus called 'macro' and 'micro'. Macro is base building, selecting which tech tree to advance down, upgrading, building your economy. Micro is controlling small groups or individual units and their position on the map and how they engage with enemy units. For a very rough idea, alternative terms would be macro = strategy, micro = tactics.
Someone who is excellent at macro can be destroyed by someone who is lousy at macro and excellent at micro, and vice versa. The top players are excellent at both macro and micro.
Scouting what your opponent is doing is a bit part of both your macro and micro strategies but in different ways. If you see the enemy has built unit factory X, then you better counter it by building Y (macro). If it's in map location Z, then you better make sure you get your units to position A to head them off (micro).
There are 3 races in SC so 6 possible match-ups include the 'mirror' matchups. If both players are random, then each player must scout their enemy to initially learn their race. Then there are known build-orders, so if you scout your enemy at time 2 minutes, and see X and Y, then you can conclude they are (probably) using strategy A. But if you get that exact same set of information at time 4 minutes, then concluding they are using strategy A may be a mistake.
Humans know these build orders (like expert players memorising important chess gambits), but the AI likely doesn't, so has to brute force everything. Brute-forcing is possible in chess, and thought impossible in Go. So Starcraft is an extension in this same area.
Lol, as if "power users" make up any more than 0.1% of the user base. Similarly I'm sure that 90% of developers don't *need* what you're pining for either.
Windows 10 with the calculator in Scientific mode gives me -8.1648465955514287168521180122928e-39
When I put it on Standard I get your number. Interesting that there's more to Scientific mode than simply extra buttons.
Woosh!
That's farming.
The US Military has already gotten that beat, too. With rectal feeding (google it), they put food directly into your ass! So you don't even have to put up with the hassle of chewing and swallowing - even more convenient than what those soylent people are doing.
Because those that had bad dental health or cavities, died early.
Unless you're going to mine, then you need some way to acquire bitcoin, generally this is by converting fiat currency at an exchange.
Since everything in bitcoin is public, the exchange could easily track what happens to the bitcoins after they leave their wallet.
What does legality have to do with anything?
Coinbase can choose who their customers are and who they give service to, just like any brick & mortar store, or any other internet service provider.
False equivalence. It doesn't say "one" programming language, it says "dominant" programming language.
Lots of people have responded suggesting various tools or whatnot. It is quite likely that you already have a good (perhaps not the best) tool for the job, and what you actually need to do is change the processes that humans are following.
The best way to approach this is to use the "5 whys" approach, where you state the problem (or group of problems) and ask "why" 5 times to try and work out the root causes, then address them.
Eg, Problem: We have too many duplicate error reports. Why? Because testers don't know about existing bugs before raising new ones. Why? Because the testers don't search for existing issues on the backlog before raising new ones. Why? Because they haven't been trained properly.
Other possible answers for the above train may be "our backlog doesn't make searching easy" or "testers don't have a consistent way of recording issues so its difficult to find the same issue raised by different testers".
Anyway, you can do the 5 why's process yourself, but some potential root causes and responses you can take:
You have too many bugs in your software, so it's going to be hard to get on top of them no matter what processes you put in place.
* Perhaps there are developers in your team who don't have a good understanding of the system and generate bad code -> training or peer-programming might help.
* Perhaps your fundamental architecture needs to be refactored / improved / better documented to reduce the incidence of bugs.
* Perhaps your team has too much work load or is under too much pressure to get features out on time that you don't have adequate time to address your bugs, and they're building up into an unmanageable pile.
* Perhaps people on your team don't think it's their responsibility to fix bugs in their own code or they don't think it's 'fun' - someone else's job - and other people aren't proficient in that area of the code and so take longer to fix the bugs, or create new bugs in the process.
* Perhaps your team is just more interested in pushing through to 'new' things, and don't take the time to clean up bugs as they go, building new code on top of bad.
Other problems might arise from the testers.
* Perhaps you have lots of different people testing the software and raising bugs (instead of a core team of a few testers who become intimately familiar with the software), and they all have their own writing style or way of recording bugs, making it hard for any tester to know if any other tester has already raised a bug.
* Perhaps your testers just don't talk to each other - "oh yeah, I saw something like that 2 weeks ago...".
* Perhaps your testers don't search through the existing issues before raising new ones - perhaps because the tool doesn't support it well, or simply no-ones told them its a good idea to do.
* Perhaps your software doesn't have a good way of reporting bugs - if your software crashes, having consistent and common output to allow testers to identify "crash X is the same as crash Y" means they don't need to raise a second bug to report Y, instead they could just find the report for crash X (by searching for unique output in the crash) and add their new incident there.
Another thing to consider is that maybe you just need to groom the backlog from time to time. Go through and look at *all* the bugs in one sitting, and you might quickly find duplicates that you can merge/link together. You might also find that there's a bunch of bugs that you know you'll just "never" fix because they aren't important, so these could be closed or moved elsewhere to minimise the noise in the system, letting you focus just on the important stuff that matters.
Don't expect that there is going to be a 'quick fix' from adopting a new tool. It is very likely that some of the above human processes are contributing to your unmanageable backlog, and moving to a new tool won't markedly change your performance.