Shared posts

23 Oct 14:12

First Experimental Evidence That Time Is an Emergent Quantum Phenomenon

by Unknown Lamer
KentuckyFC writes "One of the great challenges in physics is to unite the theories of quantum mechanics and general relativity. But all attempts to do this all run into the famous 'problem of time' — the resulting equations describe a static universe in which nothing ever happens. In 1983, theoreticians showed how this could be solved if time is an emergent phenomenon based on entanglement, the phenomenon in which two quantum particles share the same existence. An external, god-like observer always sees no difference between these particles compared to an external objective clock. But an observer who measures one of the pair — and so becomes entangled with it--can immediately see how it evolves differently from its partner. So from the outside the universe appears static and unchanging, while objects that are entangled within it experience the maelstrom of change. Now quantum physicists have performed the first experimental test of this idea by measuring the evolution of a pair of entangled photons in two different ways. An external god-like observer sees no difference while an observer who measures one particle and becomes entangled with it does see the change. In other words, the experiment shows how time is an emergent phenomenon based on entanglement, in which case the contradiction between quantum mechanics and general relativity seems to melt away."

Share on Google+

Read more of this story at Slashdot.








06 Sep 13:03

Our Newfound Fear of Risk

by Bruce Schneier

We're afraid of risk. It's a normal part of life, but we're increasingly unwilling to accept it at any level. So we turn to technology to protect us. The problem is that technological security measures aren't free. They cost money, of course, but they cost other things as well. They often don't provide the security they advertise, and -- paradoxically -- they often increase risk somewhere else. This problem is particularly stark when the risk involves another person: crime, terrorism, and so on. While technology has made us much safer against natural risks like accidents and disease, it works less well against man-made risks.

Three examples:

  1. We have allowed the police to turn themselves into a paramilitary organization. They deploy SWAT teams multiple times a day, almost always in nondangerous situations. They tase people at minimal provocation, often when it's not warranted. Unprovoked shootings are on the rise. One result of these measures is that honest mistakes -- a wrong address on a warrant, a misunderstanding -- result in the terrorizing of innocent people, and more death in what were once nonviolent confrontations with police.

  2. We accept zero-tolerance policies in schools. This results in ridiculous situations, where young children are suspended for pointing gun-shaped fingers at other students or drawing pictures of guns with crayons, and high-school students are disciplined for giving each other over-the-counter pain relievers. The cost of these policies is enormous, both in dollars to implement and its long-lasting effects on students.

  3. We have spent over one trillion dollars and thousands of lives fighting terrorism in the past decade -- including the wars in Iraq and Afghanistan -- money that could have been better used in all sorts of ways. We now know that the NSA has turned into a massive domestic surveillance organization, and that its data is also used by other government organizations, which then lie about it. Our foreign policy has changed for the worse: we spy on everyone, we trample human rights abroad, our drones kill indiscriminately, and our diplomatic outposts have either closed down or become fortresses. In the months after 9/11, so many people chose to drive instead of fly that the resulting deaths dwarfed the deaths from the terrorist attack itself, because cars are much more dangerous than airplanes.

There are lots more examples, but the general point is that we tend to fixate on a particular risk and then do everything we can to mitigate it, including giving up our freedoms and liberties.

There's a subtle psychological explanation. Risk tolerance is both cultural and dependent on the environment around us. As we have advanced technologically as a society, we have reduced many of the risks that have been with us for millennia. Fatal childhood diseases are things of the past, many adult diseases are curable, accidents are rarer and more survivable, buildings collapse less often, death by violence has declined considerably, and so on. All over the world -- among the wealthier of us who live in peaceful Western countries -- our lives have become safer.

Our notions of risk are not absolute; they're based more on how far they are from whatever we think of as "normal." So as our perception of what is normal gets safer, the remaining risks stand out more. When your population is dying of the plague, protecting yourself from the occasional thief or murderer is a luxury. When everyone is healthy, it becomes a necessity.

Some of this fear results from imperfect risk perception. We're bad at accurately assessing risk; we tend to exaggerate spectacular, strange, and rare events, and downplay ordinary, familiar, and common ones. This leads us to believe that violence against police, school shootings, and terrorist attacks are more common and more deadly than they actually are -- and that the costs, dangers, and risks of a militarized police, a school system without flexibility, and a surveillance state without privacy are less than they really are.

Some of this fear stems from the fact that we put people in charge of just one aspect of the risk equation. No one wants to be the senior officer who didn't approve the SWAT team for the one subpoena delivery that resulted in an officer being shot. No one wants to be the school principal who didn't discipline -- no matter how benign the infraction -- the one student who became a shooter. No one wants to be the president who rolled back counterterrorism measures, just in time to have a plot succeed. Those in charge will be naturally risk averse, since they personally shoulder so much of the burden.

We also expect that science and technology should be able to mitigate these risks, as they mitigate so many others. There's a fundamental problem at the intersection of these security measures with science and technology; it has to do with the types of risk they're arrayed against. Most of the risks we face in life are against nature: disease, accident, weather, random chance. As our science has improved -- medicine is the big one, but other sciences as well -- we become better at mitigating and recovering from those sorts of risks.

Security measures combat a very different sort of risk: a risk stemming from another person. People are intelligent, and they can adapt to new security measures in ways nature cannot. An earthquake isn't able to figure out how to topple structures constructed under some new and safer building code, and an automobile won't invent a new form of accident that undermines medical advances that have made existing accidents more survivable. But a terrorist will change his tactics and targets in response to new security measures. An otherwise innocent person will change his behavior in response to a police force that compels compliance at the threat of a Taser. We will all change, living in a surveillance state.

When you implement measures to mitigate the effects of the random risks of the world, you're safer as a result. When you implement measures to reduce the risks from your fellow human beings, the human beings adapt and you get less risk reduction than you'd expect -- and you also get more side effects, because we all adapt.

We need to relearn how to recognize the trade-offs that come from risk management, especially risk from our fellow human beings. We need to relearn how to accept risk, and even embrace it, as essential to human progress and our free society. The more we expect technology to protect us from people in the same way it protects us from nature, the more we will sacrifice the very values of our society in futile attempts to achieve this security.

This essay previously appeared on Forbes.com.

09 Jul 16:45

UI and UX design for OpenROV Cockpit

by Eric Stackpole

So we've been thinking a lot recently about UI and UX (User Interface and User Experience) for OpenROV, and it seems like there is a lot that can be done in this realm.  OpenROV Cockpit is the way we relate with the ROV- it's our connection to what the ROV is seeing, how it is doing, and where it is.

This is an obviously overcrowded mock-up of a possible OpenROV Cockpit screen, but it shows how a bunch of various widgets could be configured. 
Lately, I've been brainstorming ideas and trying to put together a mock-up of what my ideal OpenROV Cockpit might look like.   I expect that everyone's ideal cockpit would be a bit different (and situations may call for different looking cockpits even for the same user), but I wanted to post the mockup I made for myself and see what the ideal OpenROV cockpit would look like for other people.   This is certainly the kind of thing where there is no right answer- just different preferences.   
Here's a little about my design:
There were several driving forces behind the appearance of my ideal OpenROV Cockpit.
 
1.  Dark Background
I like having a dark background because it allows maximum contrast to be given to things shown on the screen but allows you to keep fairly good night vision when piloting in dark places.  I used shades of a color for the contrasting figures as opposed to just varying brightness of grey, because it gave me more comparative options.  I could have used shades of red instead of blue since the red light is less damaging to night vision, but I figured that the difference with such sparse features compared to how much light would be coming from whatever video image there is would be negligible, and frankly blue fits with the color theme of OpenROV and looks cooler.  I do think adding some more colors to the pallet would make things look better, and I can picture using reds (or more likely dark oranges) to indicate values that are cause for attention (such as a temperature getting to high or a voltage getting to low).   I got a lot of inspiration from one or two shots of the pretty pretty user consuls in the movie, Oblivion.
2. Form Follows Function
Superfluous features and "stylistic" objects that serve no purpose bother me to no end.  That's not to say that making something look clean or consistent with its surroundings is a bad thing, but if there is no method to a theme, then in my opinion it should be done away with.   I chose four shades of blue (let's call them "1", "2", "3", and "4" in order from darkest to lightest) and for the most part stuck with a theme of "1" for borders and boundaries, "2" for reference points, boundaries of value outputs,  and incidental labels,  "3" for primary labels , and "4" for values and plots.  Boundaries have curved corners so that it is more clear which lines go to which boxes, and lines are used to underscore primary labels to help distinguish them from values.
3. Modularity
Depending on context, different displays may be needed at different times.  Just as a combo TV, DVD, VCR, Radio set becomes blatantly unfitting once any part of it stops working or is made obsolete, being committed to data displays that are irreverent is frustrating and distracting.   Additionally, it's very nice to be able to add displays for new devises without having to make edits to a single system that you might already have.  What I think would be really cool, is if displays could be designed as widgets by various people, and a user could simply download the ones they like and insert them into their own Cockpit display.  Perhaps hardware such as sensors could even come with widgets...  Anyway, all this is food for thought now, but it seems like there is a lot of potential here.
4. Lots of Plots
In my own experience, I've found that how things are changing is often just as, if not more valuable to know then what the current state things are.  Because plots tend to take up a fair amount of real-estate, and trends upward or downward with out exacting values are sufficient for the most part, I made most plots pretty basic with a min an max value for y-axis reference, and standardized the time increment (which could be adjusted, but in this case is 30 seconds per tick) to all plots in a given section.  
For plots where the specific values are important, I used more space and labeled things more frequently.  
5. Corner-of-Eye-usable displays
This is a concept I think I could have done better with in this mock up, but at least I gave it a shot.  From my own experience, readouts that you don't have to look directly at (so you can keep your eye on the video feed) are very handy.  This can be achieved in a variety of ways.  I used "ribbon" displays for depth and heading (in addition to the numerical readouts) which give you a sense of relative moment peripherally, and I also used arrows that would light up in different places to indicate the direction of vertical movement.  (Yes these are redundant for depth, but I'm just playing around here).   The ultimate don't-take-your-eye-off-the-ball telemetry readout would obviously be a heads-up display like what Brian Adams has been working on, but I didn't feel like addressing that with this mock-up.  In general, it might be nice to have more dials and displays with more graphical (as opposed to numerical) outputs for other telemetry, but this was a start.
There is also one huge thing missing from all of this: input features.  I definitely think that clicking on things with a mouse is a pretty bad way of sending commands when your out in the field ( your hands may be busy controlling joysticks, there may be glare that impedes seeing where your mouse is, etc), but certainly this can be explored.  The growing popularity of touch-sensitive screens is very likely to have an influence on things, but in the mean time, dynamically mapping gamepad buttons and keyboard keys to different functions, and displaying what those mappings are on the screen might be the ticket.
 What excites me the most is the idea of many people contributing pieces of the OpenROV cockpit, and users being able to adopt things that are useful.  As I mentioned in the beginning of this blog, I don't think there is any "right answer" to UI and UX, but allowing people to choose what suits their needs best is a great way to progressively make interacting with the ROV better.
What is it you'd like to see in a UI for OpenROV?
20 Jun 16:40

#486 Tangled Web

by treelobsters