They could certainly send 50 times as many messages, but they'll improve their return on investment if they target all of them at people who are more susceptible to their message in the first place. Given the cost of the Big Data systems they may only be able to afford to send 10 times as many instead of 50 times, but as long as their message is 5% effective instead of 0.1%, it's still a vast improvement on ROI.
That's a great question. Do you think 80% accuracy is good enough for medical use? If you're a doctor facing an unfamiliar situation, and your data says treatment X helped 40% of patients it was tried on, treatment Y helped 35% of them, and all other treatments (Z, W, etc.) helped no more than 30%, but you know the data might only be 80% accurate, what treatment do you choose? Are those ratios even meaningful in the presence of so many errors?
Consider the case where the patient's condition is critical, and you don't have time for additional evaluation. Is X always the best choice? What if your specialty makes you better than average at treatment Y? Maybe that 20% inaccuracy works in favor of the doctor who has the right experience.
It could it be used for ill, too. What if you know you'll get paid more by the insurance company for all the extra tests required to do treatment Y? You could justify part of your decision based on the uncertainty of the data.
In the end, historical data is just one factor out of many that goes into each of these decisions. Inaccurate data may lead to suboptimal decisions, so it can't be the only factor.
You seem to be belaboring this mistaken impression that analyzing Big Data somehow replaces thinking in the board room. It does not. Big Data is a tool that can help provide evidence of what people have done in the past, statistically correlated to potential causes. Big Data doesn't decide "hey, let's buy GM." People make those decisions, and they try to make them based on the information they have -- and Big Data can be a good source of that info. But people can be idiots, they can be talented, they can be anywhere on the spectrum. Do not blame the tool, or the accuracy of the tool, just because it's capable of being swung by an unqualified, incompetent idiot.
As a friend of mine is wont to say, "A fool with a tool is still a fool."
If you're doing the Wave, you deserve to get stuffed back in that locker. Or worse.
As far as Deflate Gate goes, in the end it won't matter. The Hawks are going to walk all over the Pats. The only real question is whether they'll hit any of the numbers I drew in our office pool.
When you're dealing with statistics, you ought to recognize that 92% accuracy is a huge improvement over a random distribution. You do not use big data to select a target for a sniper rifle, you use it to point a shotgun.
And just like your faulty GM CEO analogy (I assume you felt the need to apply a car analogy for the benefit of the slashdot crowd) only an idiot would send someone off in the woods blindfolded and have him fire his shotgun in a random direction hoping to bring home some kind of food animal. You still have to know what you're hunting for, you still have to know how to hunt, you still have to make wise decisions. It's just a tool, not a sage.
This is what scares most people, or at least me, about ideas of using big data to predict criminals or otherwise mess up people's lives.
It's not a problem to use big data to try to figure out where to focus. But you have to subject the results to some sanity checking, and before you actually impact someone's life, perhaps even some common sense. Shocking idea, I know, and the reason why it's still a problem.
That phrase "fair share" is dishonest. It is vague and subjective,
A tax code which permits corporations to hide profits while taxing citizens normally is dishonest.
The difference between "92% accurate" and "accurate enough for my task" are profound.
If you were using these kind of analytics to bill your customers, 92% would be hideously inaccurate. You'd face lawsuits on a daily basis, and you wouldn't survive a month in business. So the easy answer is, "this would be the wrong tool for billing."
But if you're advertising, you know the rates at which people bite on your message. Perhaps only 0.1% of random people are going to respond, but of people who are interested, 5.0% might bite. If you have the choice between sending the message to 10000 random people, or to 217 targeted people (only 92% of whom may be your target audience), both groups will deliver the same 10 hits. Let's say the cost per message is $10.00 per thousand views. The first wave of advertising cost you $100. The second costs you $2.17. Big Data, with all of its inaccuracies, still improves your results by a wide margin.
Way too often people like this point out that perfection is impossible. They presume that "because it's not perfect, it's useless." The answer is not always to focus on becoming more accurate, but to choose the right tool for the job, and to learn how to recognize when it's good enough to be usable. At that point you learn how to cope with the inaccuracy and derive the maximum benefits possible given what you have.
Or put another way, If big data is so great "Why didn't Watson see IBM's crash coming ?"
You're assuming it didn't.
problem with Noscript et al, is the same problem with softwalls like Zonealarm - the content is already downloaded to your computer for the parser to analyse before it's passed to the rendering engine. It's already in your system.
Well, yes and no. The script embedded in the html or whatever is already in your system, but any linked script files hosted on a dodgy domain don't actually get downloaded at all, at least on Firefox. In the past this was impossible on chrome by design, but I'm told it works properly now. The flash and most of the script is never in fact downloaded to your PC at all.
Thanks for the info. I went with the premise that they were the only Android phones guaranteed to get software updates. Now I am just confused as how to know a good Android phone that will be in the front running for getting system updates, without having to jailbreak.
What you do get with Nexus devices is unlockability. But you also get that with Motorola and even Sony devices. You void your warranty in the process, which probably isn't strictly legal for them to do to you. You can relock your phone so that it can get OTAs again, though... at least in the case of Motorola. Dunno about others. What you just can't assume you get is quality.
Because "a while" might be like 10 15 minutes. When all you want to do is unplug, go out and start jamming, that sucks as UX.
So if you care, then you use a tool. But being forced to use a tool is still bullshit, and you are still a useful idiot apologist.
plus no worrying about what happens if the device writes garbage to the config, or what happens if power is lost mid write, etc.
Actually, all that stuff can still happen to iPods.
author David Geary
pages 615 pages
publisher Prentice Hall
The reason this book gets a nine is it accomplishes everything it sets out to do and Geary does a great job dividing up task after incremental task of setting sprite sheets and backgrounds into motion. The reason it doesn't get a ten is that I was personally disappointed with the the author devoting little time to physics and their simulations.
The book is laid out to enable its use as two kinds of resources: cover to cover and chapter specific topics. Reading this straight through, there were only a few times where it felt like I was needlessly being reminded of where I had already read about tangential topics. On the plus side if you ever want to see how Snail Bait implemented something like sound, you need only spend time on the chapter devoted to sound sprites. One mild annoyance I had with the text was that the author seems to always refer to Snail Bait as “Snail Bait” which leads to a Ralph Wiggum-like aversion to pronouns or saying “the game” instead occasionally. It might only be me but it can become tiresome to read “Snail Bait” five or six times on the same page.
You can read a sample chapter here that shows how to implement sprite behaviors.
The third chapter delves into draw and rendering graphics in the canvas as well as introducing the reader to the game loop. It spends a good amount of time explaining the use of animation frame control in a browser to keep animations running smoothly. It also begins the auditing of frame rates so that the game can respond to and display things normalized at the rate the user is experiencing them. It also touches on how parallax can be employed to show things closer up moving faster than those further back in the background. This illusion of depth has long been popular and is even finding its way into scrolling on blogs and I wish that Geary would have spent more time on this perhaps in a later chapter but offer the reader more on how to do multiple levels of depth.
The next three chapters cover the use of loading screens, sprites and their behaviors. Snail Bait uses all its graphics from an open source game (Replica Island). But if you were to design your own graphics for your game, these chapters do a great job of showing how to construct sprite sheets and how to use tools to construct metadata in the code so that the sprites are usable by the sprite artists. Using the flyweight pattern, Geary sets the stage for more complex behaviors and actions to come in the following chapters.
The next three chapters cover time, stopwatches and their effects on motions and behaviors within the game. The author starts and works from linear motion to non-linear motion and then using transducer functions to affect the time system. The game now has bouncing coins, a jumping player and Geary does a good job of showing the reader how to emulate behaviors in the code.
Naturally what follows next is collision detection and gravity. The collision detection strategies were adequate but I wish that there was more depth at least referenced in the text. This isn't a simple problem and I did like how Geary referenced back to chapter two’s profile and showed how collision detection performance as you implement and refine and optimize your algorithm. The nice thing about this book is that it often tackles problems with a general solution in the code (runner/sprite collision) and then provides the edge case solutions.
In the fourteenth chapter, the author tackles something that has long been a plague in HTML5 games: sound and music. The author doesn't sugarcoat this citing the long history of problems the vendors have had trying to support this in browsers. There’s a great explanation of how to create and handle “sound sprites” (similar to sprite sheets) so that there is only one download for background music and one download for audio sprites.
Next Geary covers the problem of multiple viewport sizes with a focus on mobile devices. Of course this is one of the biggest issues with mobile gaming today. The chapter is lengthy and deals with the many intricacies of scaling, sizing and touch events. This chapter is long but the highly detailed support of multiple platforms and resolutions is a justified discussion point.
In sixteen, the reader gets a treatment of utilizing sprites and their artists to simulate sparks and smoking holes. The book calls this chapter “particle systems” but I don’t think that’s a very good title as the code isn't actually dealing with things at the particle level. Instead this chapter focuses on using sprites to simulate those behaviors via animation. This is completely necessary on a computation inexpensive platform but it is misleading to call these particle systems.
Now that the game looks and functions appropriately, the book covers UI elements like player scores and player lives. The auditing of these metrics are covered in the code as well as warnings when the game begins to run to slowly. It also covers the ‘edge’ condition of winning in the game and the routine that is followed when the user wins the game.
The next chapter introduces the concept of a developer backdoor so that the reader can manually speed up or slow down the game while playing it or even test special cases of the runner sprite interacting with other elements. It’s a useful trick for debugging and playing around but does devote a lot of time to the specialized UI like the speed slider and other things that won’t (or rather shouldn't) be seen by a common player.
Chapter nineteen really felt out of place and very inadequate on important details. It’s a blind rush through using node.js and socket.io to implement server side high scores. The way it’s implemented would make it trivial for someone to submit a high score of MAX_INT or whatever to the server. The metrics reporting is done in a manner that (in my opinion) breaks from long established logging structure one would be familiar with. While it covers important things to record from your users in order to tweak your game, the inadequacy of discussions about shortcomings makes it feel out of place in this text. It's a topic of great depth and I have no problem with an author touching on something briefly in one chapter — this chapter does lack the warnings and caveats found in other chapters though.
Contrary to the previous chapter, the final chapter is a fast application of the entire book’s principles applied to a new game (Bodega’s Revenge). Geary gives a final run through showing how the lengthy prior discussions quickly translate to a new set of sprite sheets and game rules. If this book is ever expanded, I think it would be great to include additional chapters like this although I would pick a more distinct and popular two dimensional game format like a tower defense game or a bejeweled knockoff.
Link to Original Source
Just like they tell you that you any time you think you might be being pulled over by someone who's not a real cop (say, an unmarked car), you can drive to the parking lot of a police station before pulling over.
Disclaimer: That only works if you are white.
there is a Flash exploit that STILL isn't patched, that only requires a user to visit a site with a bit of compromised embedded flash content like a banner ad, and BOOM, owned. You don't even have to click a link, just visit a domain hosting the content on a page.
I notice your account was created yesterday. Please let me be the first to welcome to you Slashdot.
Maybe you could tell us a little bit about yourself, by way of introduction. Like maybe your badge number.