An electron "has spin 1/2." By this, it is meant that the magnitude of its spin, if measured is 1/2. This is true.
But spin is a vector -- it can point in any direction in space. Thus it has a direction too (hence the plus or minus).
That answers your question, but at this point you might wonder why it is assigned either plus or minus 1/2 and not any arbitrary vector. The answer is that due to the weirdness of the spin space (that is, where the electron's spin "lives"), it can be described as a projection onto the plus and minus 1/2 spin vectors along a particular axis. You are, of course, free to choose your axis.
This is an important point that I think the article really butchers: as far as I can tell (and I am a condensed matter physicist), they are *NOT* actually creating fundamental superstrings, i.e. those predicted by string theory. Rather, they are creating objects in BEC's that behave in exactly the same way as predicted by that theory.
To use a computational analogy, they are simulating the equations of string theory using a BEC as the computer. So whatever results they get had better agree with string theory! They aren't actually testing whether these explain the world, just exploring the equations of string theory with an efficient computer -- the BEC.
If some object is made up of an even number of fermions, it is a boson, otherwise it is a fermion (the neutrons and protons that make up the nuclei of the atom are each fermions, as are the electrons surrounding it).
Now, for the reason: if you know some quantum physics, think of taking two composite objects and interchanging them; fermions wavefunctions change sign under this interchange. For the composite object, its wavefunction looks like (an anti-symmetrized) product of single-particle wavefunctions. If those are fermionic and there are an odd number of them in the composite wave function, interchanging the two composite wavefunctions will produce an odd number of sign changes in the product, for an overlal sign change. If there are instead an even number of fermionic single-particle wavefunctions in the composite wavefunction, the resulting even number of sign changes under interchange produces no net sign change in the many-body wavefunction.
This is easily extended to composite objects that are a composite of both bosons and fermions.
Re:The performance of compiled code
on
A Review of GCC 4.0
·
· Score: 2, Insightful
I think that companies should re-evaluate their "need" for an extra 5% performance. Here's an idea -- if you need something 10 minutes faster, why not start the process 10 minutes sooner?
Is this a troll? In most high-performance computing environments (national and local supercomputing centers) -- at least when they are being well-utilized -- they are in non-stop use. You don't start ten minutes sooner because you or another user are hammering the machine with other jobs.
Right on! And those 50 textbooks I had to read in college, complete waste of time. I mean, reality does not change because some professors who wrote those textbooks believe something is so.
Even if it develops the logic in the text and gives references to the starting assumptions so is easily verifiable... Oh, wait. No. I guess that is the complete opposite of waste of time. ***cancel post***
Still I, and lots of people I know, can work 10-12 hours a day, 7 days a week. This is not uncommon in the sciences in academia, nor in several ``professions.'' I think some people just enjoy/value work more than others; they just have different levels of work at which they feel balanced.
So I hope that those programmers working the long hours are doing this because it's what they have a passion for. Unfortunately, I fear your point is probably correct.
This argument doesn't sit well with me; if game development (or other) teams at company A had more "realistic" timelines the competitors would get their game out before those at company A. Company A's employers would be out of a job.
Hell, all the programmers' jobs you're trying to make better would rather be working the 12 hours at the competitor than not working at their newly out-of-business game shop.
Now, there are questions of these longs hours affecting quality, as you said. The real question to be answered is: in that last hour, is anything productive done? Of course the coders are not as fresh and productive as they would be a lower schedule, but as long as more good coding is being done than mistakes being made, it could still be worth the work.
All that said, I'm sure there is room for better management of the projects.
I don't personally about elliptic function-based cryptography, so I will trust you. I do take issue with your statement, however, that "Presently only two useful algorithms for quantum computers are known."
There are a number of algorithms for simulating model quantum systems, which I think will ultimately be among the most useful algorithms. They will allow unprecedented accuracy for studying the dynamics of quantum systems, allowing materials design and who-knows-what. Also, there is a quantum algorithm for diagonalizing matrices exponentially faster that could be extremely useful (but still need to be careful about measurement -- you have to measure exponentially fewer items than you put in to get the speed-up; fortunately, this is often all you desire anyway).
But I agree with the conclusion that other asymmetric schemes are presently unbreakable on a quantum computer.
Encryption, as it stands now (the classical kind), relies on an asymmetric computational task. For example, it is much easier to check that the a list of numbers are the factors of another number than it is to factorize the number. In fact, the latter is, to the best of current computer science knowledge, exponentially slower than the first.
Quantum computing provides an algorithm (Shor's), utilizing quantum mechanical manipulations, which factors numbers exponentially faster. Thus, factoring and checking factors takes the same amount of time.
This leads to the undesirable conclusion that encryption and decryption (by an intercepting 3rd party) of a signal take the same amount of time (up to a polynomial equivalence). In other words, the encryption is breakable, since the interceptor need only invest roughly the same amount of computational effort as the sender in order to crack the message.
That is why the creation of a quantum computer would "obsolete" present encryption. The point of quantum encryption is that it is not vulnerable to such attacks.
No. Some things happen instantaneously in the theory (quantum mechanics)-- but these cannot be manipulated to transmit information.
A (very slightly) more precise way of stating this is that quantities within the theory seem to be transmitted instantaneously, but that these quantities are not available for use... It may sound suspicious, but it's true (where of course, very particular things are meant by the rather vague words I have chosen).
In cryptography, the information is sent using entanglement of particles, but this does not allow instantaneous communication; this is a common misconception. The breakthrough is not instantaneous communication, but rather in provably secure communication (again, in a quite particular sense). A doubling of bandwidth might also be possible, but my memory is failing me on the details of quantum teleportation/cryptography.
Every feature you asked for is in Opera except in-page bookmarks.
(1) side-by-side viewing of different parts of a page: Since one has tabbed browsing, just open a new window with two tabs of the same page (or just one, and "Duplicate" -- it retains the other ones history as well). Now click "Window->Tile vertically" (or press Shift+F6). Firefox probably has this feature, as well. 2 shortcuts, or two menu items. quick! Not 100% sure if this is what you were thinking of.
(2) Side-by-side viewing of different pages. Can do the same as one, but don't duplicate -- open new page. As a bonus, if you are thinking of having links from one page always open in the second window, you can do this in opera as well (play with Window->create linked). Instead of always appearing in either the same page or in a NEW background page, links appear in the specified second page.
(3) To open all links, click on the "links" icon to open your links panel. This displays all links in the page. Now press shift+left mouse button to select all the links you want to open. In other words, two clicks+drag (with shift) -- all on items appearing in the main interface -- will do it. About the same effort as opening a file or saving a new file.
The problem is that you can't have different representations! You are still stuck with one. As soon as you compile to the underlying language, you cannot uncompile. Names are scrambled, etc.
Here's one of my favorite ideas for graphical programming (besides higher level design, like UML, etc.), which barely uses graphical elements:
Say you have a if statement, or alot of nested if's. If the blocks have any substantial size, it is impossible to see the flow and connection of the state prior to the conditional and after the conditional precisely because you have to jump back and forth. It requires enough time to look at the code to basically memorize the input state or the output state. Watch experienced programmers sift through unfamiliar code with such blocks. They jump back and forth, precisely like this.
By blocking each separate conditional in a rectangle (nested if necessary, can scroll through the text in each rectangle) the hierarchical structure (parse tree) becomes apparent much more easily. The textual commands are still there, but this shows the layout of the individual commands simultaneously with retaining the speed and expressiveness of text.
I imagine that text will continue to be the primary mechanism by which programming is done (I would take C++, Java, or even VisualBasic over LabView for ordinary programming tasks, for example), but I imagine graphical elements for ORGANIZING those textual statements will be important. And some levels of viewing the code may suppress the code altogether (for example, UML-like modeling).
So the idea of wiring icons together and programming like this is probably doomed to failure, graphical organization of textual programming, I believe, has great potential. At least, it is worth having a go.
You're hitting at a really deep point. Learning from others' mistakes will be impossible if the mistakes in one representation translate to mistakes in a different representation in a way such that mistakes made in one representation would not typically be made in another.
Of course, this could be support for this idea, as a programmer learns a few representations of the same code and can switch between them, he/she can see the mistakes obvious in some representations.
Now, you can still give your code to a buddy and they may fix your problem in their own representation and hand it back to you in your own representation, but if the mistakes are so un-obvious in the representation they have set up, no luck. So probably, programmer's using drastic changes in syntax representation would have to learn a couple very different representations to collaborate effectively. But these are the programmer's who would probably find no problem in this. And many would use it just for syntactic sugar, and that would be fine. I think there would be little/no problem with sharing and learning from mistakes across representations as long as indentation/braces/etc. were the only things being changed.
But if obvious mistakes in one representation translate to obscure ones in another, things could be difficult in collaborations if people are using very drastic changes . Thanks for pointing this out -- I had considered static code, and code in development, but not necessarily the value of mistakes in code and the necessity to share them for development. One point may be to not allow drastic enough changes for this to become an issue (though in fact it may be a virtue to allow that diversity of representations). Again, thanks.
I wonder if you could find two real programming languages that you could usefully and bidirectionally translate between and not lose a lot in the process.
You have boiled things down to the essence of the problem. This is the real question. This is why I primarily stuck with simple examples like indenting -- easy bidirectional correspondence. As we shift between more elaborate language features, and/or allow programs to include any layout for which there isn't a 1-1 correspondence, things will go apeshit and impossible to maintain, I suspect.
So, within that constraint, can anything really useful be done? At least some, I think. Maybe some really useful things... but this is the question that needs to be answered.
This is a valid point. Nonetheless, refer to the recent article on Code Complete on Slashdot. Many references are made to the section on indenting. 2-4 spaces is best. Ideally, we would be infinitely flexible, but there is something about our brains/culture that fixes us towards that. The first thing that one should consider when one learns there is an average behavior in such phenomena is to consider that this is always accompanied by fluctuations. So, each user will have an optimal indentation readability.
And some people prefer perl's $_ (and other shortcuts) as a useful shortcut; some prefer to write things more explicitly. Neither is better or worse, and coping with a way you do not prefer takes effort. Not terribly, but when you have 100,000 lines of someone else's code to understand and modify very quickly, you should take all the minor speed improvements you can get. I am not exactly a software developer, but my colleagues and I often develop applications. We generally collaborate and look at each others code. It is readable and not particularly difficult. But if other designer's preferences matched mine, it would be easier to read, and over time this speed improvement would amount to something substantial.
As long as representation-independent code is what people were using, I don't see this "training yourself to strongly prefer some kind of private language" as being a bad idea. Additionally, the potentials for graphical programming and alternative paradigms could be really interesting; exploring these would not be overly detrimental/risky. If things started to go sour with one set of trial display/programming options, you could switch to a more comfortable/conventional style with no problem, instead of having to start the project from scratch.
Besides, at the very least, it gives you automatic alternative ways of viewing code -- could having the same bit of code (well) translated between perl, c, python, and java be detrimental? It can only open you to new ways of looking at the same problem. (ignore the fact that these languages are probably too disparate for this to be feasible.)
I apologize for not knowing more about.NET. From what I had understood,.NET had a few, hard-coded languages compiled to the same bytecode (e.g., J#, C#, C++, VisualBasic).
I am interested in having fully flexible syntax, instead of just a few hard-coded options. My favorite example for somewhat extreme flexibility (aside from graphical programs) is being able to use perl's special variables, but basically as macros. They might be hardcoded in the underlying language in "expanded form." (Or conversely, they might be stored as macros in the underlying language, but abbreviated in the representation if the user desired.) How flexible is.NET? Seemingly, though, this is a step in the right direction. Just curious: how open is.NET and how much is included in Mono? (Also, as I mentioned, I wouldn't mind snookering a few language features in with this idea, as well.)
Slashdot Mirror
But spin is a vector -- it can point in any direction in space. Thus it has a direction too (hence the plus or minus).
That answers your question, but at this point you might wonder why it is assigned either plus or minus 1/2 and not any arbitrary vector. The answer is that due to the weirdness of the spin space (that is, where the electron's spin "lives"), it can be described as a projection onto the plus and minus 1/2 spin vectors along a particular axis. You are, of course, free to choose your axis.
Some are bosonic, some are fermionic. See my reply to parent.
To use a computational analogy, they are simulating the equations of string theory using a BEC as the computer. So whatever results they get had better agree with string theory! They aren't actually testing whether these explain the world, just exploring the equations of string theory with an efficient computer -- the BEC.
Now, for the reason: if you know some quantum physics, think of taking two composite objects and interchanging them; fermions wavefunctions change sign under this interchange. For the composite object, its wavefunction looks like (an anti-symmetrized) product of single-particle wavefunctions. If those are fermionic and there are an odd number of them in the composite wave function, interchanging the two composite wavefunctions will produce an odd number of sign changes in the product, for an overlal sign change. If there are instead an even number of fermionic single-particle wavefunctions in the composite wavefunction, the resulting even number of sign changes under interchange produces no net sign change in the many-body wavefunction.
This is easily extended to composite objects that are a composite of both bosons and fermions.
Is this a troll? In most high-performance computing environments (national and local supercomputing centers) -- at least when they are being well-utilized -- they are in non-stop use. You don't start ten minutes sooner because you or another user are hammering the machine with other jobs.
Even if it develops the logic in the text and gives references to the starting assumptions so is easily verifiable... Oh, wait. No. I guess that is the complete opposite of waste of time. ***cancel post***
Probably the sysadmins...
Ever see the wildly popular movie "Airplane"? (imdb it yourself! :-D)
I'm sure he really wants to grind up women in the freezer.
Wow...
Still I, and lots of people I know, can work 10-12 hours a day, 7 days a week. This is not uncommon in the sciences in academia, nor in several ``professions.'' I think some people just enjoy/value work more than others; they just have different levels of work at which they feel balanced.
So I hope that those programmers working the long hours are doing this because it's what they have a passion for. Unfortunately, I fear your point is probably correct.
Hell, all the programmers' jobs you're trying to make better would rather be working the 12 hours at the competitor than not working at their newly out-of-business game shop.
Now, there are questions of these longs hours affecting quality, as you said. The real question to be answered is: in that last hour, is anything productive done? Of course the coders are not as fresh and productive as they would be a lower schedule, but as long as more good coding is being done than mistakes being made, it could still be worth the work.
All that said, I'm sure there is room for better management of the projects.
It's Senate Staffer's friend's Slashdot nick.
We execute people for high crimes, not for having ideas with which we do not agree.
Did the Waco/Koresh incident involve a high crime?
There are a number of algorithms for simulating model quantum systems, which I think will ultimately be among the most useful algorithms. They will allow unprecedented accuracy for studying the dynamics of quantum systems, allowing materials design and who-knows-what. Also, there is a quantum algorithm for diagonalizing matrices exponentially faster that could be extremely useful (but still need to be careful about measurement -- you have to measure exponentially fewer items than you put in to get the speed-up; fortunately, this is often all you desire anyway).
But I agree with the conclusion that other asymmetric schemes are presently unbreakable on a quantum computer.
Quantum computing provides an algorithm (Shor's), utilizing quantum mechanical manipulations, which factors numbers exponentially faster. Thus, factoring and checking factors takes the same amount of time.
This leads to the undesirable conclusion that encryption and decryption (by an intercepting 3rd party) of a signal take the same amount of time (up to a polynomial equivalence). In other words, the encryption is breakable, since the interceptor need only invest roughly the same amount of computational effort as the sender in order to crack the message.
That is why the creation of a quantum computer would "obsolete" present encryption. The point of quantum encryption is that it is not vulnerable to such attacks.
okay, time to stop watching so much sci-fi channel...
A (very slightly) more precise way of stating this is that quantities within the theory seem to be transmitted instantaneously, but that these quantities are not available for use... It may sound suspicious, but it's true (where of course, very particular things are meant by the rather vague words I have chosen).
In cryptography, the information is sent using entanglement of particles, but this does not allow instantaneous communication; this is a common misconception. The breakthrough is not instantaneous communication, but rather in provably secure communication (again, in a quite particular sense). A doubling of bandwidth might also be possible, but my memory is failing me on the details of quantum teleportation/cryptography.
(1) side-by-side viewing of different parts of a page: Since one has tabbed browsing, just open a new window with two tabs of the same page (or just one, and "Duplicate" -- it retains the other ones history as well). Now click "Window->Tile vertically" (or press Shift+F6). Firefox probably has this feature, as well. 2 shortcuts, or two menu items. quick! Not 100% sure if this is what you were thinking of.
(2) Side-by-side viewing of different pages. Can do the same as one, but don't duplicate -- open new page. As a bonus, if you are thinking of having links from one page always open in the second window, you can do this in opera as well (play with Window->create linked). Instead of always appearing in either the same page or in a NEW background page, links appear in the specified second page.
(3) To open all links, click on the "links" icon to open your links panel. This displays all links in the page. Now press shift+left mouse button to select all the links you want to open. In other words, two clicks+drag (with shift) -- all on items appearing in the main interface -- will do it. About the same effort as opening a file or saving a new file.
The problem is that you can't have different representations! You are still stuck with one. As soon as you compile to the underlying language, you cannot uncompile. Names are scrambled, etc.
Say you have a if statement, or alot of nested if's. If the blocks have any substantial size, it is impossible to see the flow and connection of the state prior to the conditional and after the conditional precisely because you have to jump back and forth. It requires enough time to look at the code to basically memorize the input state or the output state. Watch experienced programmers sift through unfamiliar code with such blocks. They jump back and forth, precisely like this.
By blocking each separate conditional in a rectangle (nested if necessary, can scroll through the text in each rectangle) the hierarchical structure (parse tree) becomes apparent much more easily. The textual commands are still there, but this shows the layout of the individual commands simultaneously with retaining the speed and expressiveness of text.
I imagine that text will continue to be the primary mechanism by which programming is done (I would take C++, Java, or even VisualBasic over LabView for ordinary programming tasks, for example), but I imagine graphical elements for ORGANIZING those textual statements will be important. And some levels of viewing the code may suppress the code altogether (for example, UML-like modeling).
So the idea of wiring icons together and programming like this is probably doomed to failure, graphical organization of textual programming, I believe, has great potential. At least, it is worth having a go.
Of course, this could be support for this idea, as a programmer learns a few representations of the same code and can switch between them, he/she can see the mistakes obvious in some representations.
Now, you can still give your code to a buddy and they may fix your problem in their own representation and hand it back to you in your own representation, but if the mistakes are so un-obvious in the representation they have set up, no luck. So probably, programmer's using drastic changes in syntax representation would have to learn a couple very different representations to collaborate effectively. But these are the programmer's who would probably find no problem in this. And many would use it just for syntactic sugar, and that would be fine. I think there would be little/no problem with sharing and learning from mistakes across representations as long as indentation/braces/etc. were the only things being changed.
But if obvious mistakes in one representation translate to obscure ones in another, things could be difficult in collaborations if people are using very drastic changes . Thanks for pointing this out -- I had considered static code, and code in development, but not necessarily the value of mistakes in code and the necessity to share them for development. One point may be to not allow drastic enough changes for this to become an issue (though in fact it may be a virtue to allow that diversity of representations). Again, thanks.
You have boiled things down to the essence of the problem. This is the real question. This is why I primarily stuck with simple examples like indenting -- easy bidirectional correspondence. As we shift between more elaborate language features, and/or allow programs to include any layout for which there isn't a 1-1 correspondence, things will go apeshit and impossible to maintain, I suspect.
So, within that constraint, can anything really useful be done? At least some, I think. Maybe some really useful things... but this is the question that needs to be answered.
And some people prefer perl's $_ (and other shortcuts) as a useful shortcut; some prefer to write things more explicitly. Neither is better or worse, and coping with a way you do not prefer takes effort. Not terribly, but when you have 100,000 lines of someone else's code to understand and modify very quickly, you should take all the minor speed improvements you can get. I am not exactly a software developer, but my colleagues and I often develop applications. We generally collaborate and look at each others code. It is readable and not particularly difficult. But if other designer's preferences matched mine, it would be easier to read, and over time this speed improvement would amount to something substantial.
As long as representation-independent code is what people were using, I don't see this "training yourself to strongly prefer some kind of private language" as being a bad idea. Additionally, the potentials for graphical programming and alternative paradigms could be really interesting; exploring these would not be overly detrimental/risky. If things started to go sour with one set of trial display/programming options, you could switch to a more comfortable/conventional style with no problem, instead of having to start the project from scratch.
Besides, at the very least, it gives you automatic alternative ways of viewing code -- could having the same bit of code (well) translated between perl, c, python, and java be detrimental? It can only open you to new ways of looking at the same problem. (ignore the fact that these languages are probably too disparate for this to be feasible.)
Do you think this would be easily extensible to graphical programs? What about automatically "expanding" perl's special variables?
I am interested in having fully flexible syntax, instead of just a few hard-coded options. My favorite example for somewhat extreme flexibility (aside from graphical programs) is being able to use perl's special variables, but basically as macros. They might be hardcoded in the underlying language in "expanded form." (Or conversely, they might be stored as macros in the underlying language, but abbreviated in the representation if the user desired.) How flexible is .NET? Seemingly, though, this is a step in the right direction. Just curious: how open is .NET and how much is included in Mono? (Also, as I mentioned, I wouldn't mind snookering a few language features in with this idea, as well.)