Except that the basic research has been done, fusion has been demonstrated. Yes, there are still some significant materials and confinement hurdles to achieve a commercially viable system, but it is primarily a engineering challenge, not a basic research one.
You don't invest in money, whether it is fiat currency or bitcoin currency. You invest in things that are known to have long term desirable value. You may speculate on currency fluctuations (and futures, and so on), you might even do well out of it, but that can only work while there is liquidity in the system, while transactions are being made.
For bitcoin to have long term desirable value, it has to have a purpose. It's purpose is to make transactions, at the moment specifically catering to a desire for anonymity. However, in order for there to be transactions, there has to be both a buyer and a seller, and this can only happen if the currency is stable. In unstable currencies, all transactions cease (because either buyers or sellers stop trading, depending on the direction of the instability).
At the moment the bitcoin currency is relatively stable (allowing for the small size of the economy), as mining replaces the bitcoins that have been squirrelled away into 'investment' accounts. As mining becomes exponentially more difficult, the deflation will also increase exponentially. Initially, that will simply increase the value of a bitcoin. At some point though, either people will start to bail out when they see the end in sight (which happens when there aren't enough sellers in the system), or the satoshi will no longer be small enough...
There's no point in having a million dollars worth of bitcoins if you can't spend them on something you actually need or want.
Don't get me wrong, I like the idea of a peer based financial system, and I watch the bitcoin experiment with interest. It has technical merit, but I am not convinced of its long term stability. And stability is the key factor in a sustainable trade system.
It is a software implementation of OpenGL, but it now also provides the libGL glue to various hardware acceleration drivers. So it does have a role on most Xorg systems. An exception is the Nvidia proprietary infrastructure (which replaces large portions of the normal 3D graphics stack).
Language boundaries are defined by mutual intelligibility of the communication system. This can be simplistic, but it provides a good first approximation that is testable. There are border cases (such as language chains), but on the whole it is a useful definition.
In comparison, dialect contours are defined in terms of specific language features. What speakers call a "dialect" is an identification, and while this may correspond roughly to collections of language features, it is really a sociolinguistic definition of language variety.
The notion of race is analogous to these sociolinguistic definitions, not to language; it is not defined by external factors, but by social ideas. There may be superficial features that are assumed to be associated with particular "races" (much as superficial language features are assumed to be associated with particular dialects), but these features are a poor definition of "race", because they are not clustered, and cross the boundaries of what people perceive as "race". In other words, "race" is a social construct.
It is the notion of species that is analogous to language. Species boundaries are defined by fertile offspring. Again, there are border cases, but it is testable.
I agree. Semantics (the relation of language to meaning) is important. I wasn't defending HP's misuse of the word 'memristor'.
Re:What gives? As long as it's close enough...
on
The HP Memristor Debate
·
· Score: 5, Interesting
The issue here isn't the imperfection of the HP device. It is a matter of semantics.
The 'memristor' was conceived as a term to describe a basic device where the change in flux is related to the change in charge.
What HP have produced is a device that substantially behaves like a memristor, if you are only measuring current and voltage at the terminals. That's useful if you want to build a memory device, since the behaviour is such that resistance will vary with the integral of the current through it.
However, the physics by which the HP device works is not a physics of memristance. For practical purposes, that may not matter; it is a simple device with useful properties. But terminology wise, it is memristance behaviour, not an unqualified memristor.
Equivalently, one can build an active circuit that uses a capacitor and a feedback loop to emulate an inductor. It isn't technically an inductor at all, but it does get called an "active inductor".
The advantage of the object oriented paradigm is not primarily that it makes programming easier or faster. It is the better support of separation between different components, which makes it possible to contain the complexity of large projects with multiple software engineers.
Of course, there are other ways of handling large projects (for example, there are examples of large projects written in C that control complexity by conventions about the separation of data and modules). But the object oriented paradigm is a common choice for large software engineering projects.
You might miss this when learning from a text book, since you are often only given small code examples and toy object hierarchies. But that extra 'overhead' around the defining of object abstraction pays off as the complexity increases. For many problems, thinking in terms of objects rather than instruction sequences can make the problem easier to solve.
Starting off with C and moving to C++ is not necessarily a good process, as you will not begin to learn to think in terms of objects; it is a completely different way of problem solving. Even for experienced programmers, the transition from C to C++ can be a six month process, not because of the extra language features, but because it requires a change in approach. Many don't stick at it long enough to realize the benefits.
The trade-off over speed is not an issue at all; for example, C++ is not significantly slower than C. Speed is affected far more by other choices; data structures and algorithms, memory localization, parallelism, and so on.
And you would also be aware that there are other paradigms as well, such as functional programming. These paradigms are not just "different tools for the job". They can have a radical impact on problem solving methods.
Your topic was whether nuclear weapons will keep 'non-fanatical' countries out of a war. My point is that you are overconfident of the rationality of the two countries that maintain the bulk of nuclear weapons. Woodrow Wilson taked about "the war to end war". Now you say that nuclear weapons are the weapons to end all major wars. Forgive my skepticism; I base this on past behaviour, not on suppositions about whether large states will or will not join a conflict. We are still over reliant on wise and considered decision making (such as the judgement call by Stanislav Petrov); I don't think we can take that short term stability for granted. If the assassination of a single person in Bosnia can lead to a world war, what do you imagine might happen if a nuclear weapon was used to murder an entire city?
The reason that the command line survives is that it is a model of the way that humans communicate abstract concepts - primarily using language, not using pictures. Yes, there are plenty of examples where a picture is worth a thousand words. For many applications (such as one-off editing of a photograph) a GUI makes a lot of sense. But there's no need to rip out the language facility from the user interface!
If you were going to criticize the command line interface, it would be to criticize the poor "grammatical constructions" (the inconsistent syntax and quoting methods), and the poor "semantics" (difficult to remember option codes, hard to access manuals). But these are arguments for improving the command line interface, not for discarding it. The prime reason that puts people off using the command line interface is that there are no hints as to what to type next, no feedback. It is a problem we should address.
A graphical interface is quite poor for some things, for example "do this a thousand times". The problem isn't the "thousand times"; easy enough to have a GUI element that handles it. The problem is the denotation "this", an abstraction that is hard to visualize. At best, you represent "this" as a macro sequence of GUI actions, but that is only a single level of abstraction with no parameterization. A command line interface can handle such abstractions with ease.
While ground turbulence is going to detract from peak performance, in level flight helicopters do benefit from translational lift, which increases the weight capacity. On take off, you cannot achieve forward motion until you are off the ground; ground effect helps to gain ground clearance in order to start moving forward under heavy loads. Thus the maximum load can potentially be higher than can be maintained in a hover (not that I'm saying this is necessarily a desirable scenario). In mountainous terrain, the pilot may make use of a descent to gain the forward speed rather than ground effect.
Reminds me of an interesting case in the 1970s in Australia. Edward Ward shot a fisherman on the Murray riverbank near Echuca, and the body ended up half in the water. He was found guilty of murder in Victoria. But because the boundary wasn't well defined (the river itself belonged to NSW), there was a drawn out legal battle that eventually ended up in the High Court having to define the boundary more precisely. Ward didn't get a reprieve though, because he was retried in NSW and still got life imprisonment.
The implementation of the state machine is of less interest because it is finite. The aim of the exercise is to reduce the the notion of computability to a machine-like process. The most simple conception is that only one part of the machine is infinite and variable. That is why Turing needed to show how to implement a Universal Machine as a single Turing Machine, so that the transition table could be made fixed in size (and after that point, uninteresting in implementation). It would have been sufficient to posit a human reading a pencil and paper transition table and methodically applying the transitions to the tape; the important part is that the process is "mechanical" meaning without the involvement of creativity, not "mechanical" meaning that it can be realized in a mechanical form.
Of course, if you want to build a model of a Turing Machine, then the implementation does become more interesting, so I agree with you that this Lego model is only half of the puzzle.
Chomsky's theories date back to the 1950s, and while they have their flaws, his exposition of transformational grammar was a sea-change in the study of syntax. You can't both at the same time claim that (a) he "didn't invent" anything, and (b) that he "did ruin several generations of thought on language and communication" with that thing that he didn't event.
You are also confused about the particular replicability of his generative grammars on computers; Chomsky's particular version of the generative grammars have proven less easy to implement in computerized natural language processing than some of the other more deterministic phrase structure grammars, and for many languages with free word order, dependency grammars have been a easier choice.
And the reality now is that a lot of NLP projects have given up on defined grammars and resorted to stochastic models; because for many applications people don't care about defining syntax at all (which requires time-consuming language study), they just care about outcomes. Unfortunately this has meant that success rates have plateaued after the initial quantum improvement, because while stochastic models are "relatively easy to mimic in computers", they don't always add insight into how human language works. "Doing science" when it comes to syntax involves more than just evaluating the social statistics of language use, it also includes modeling the generative power of human language.
It isn't enough to criticize the Euro-centric nature of transformational grammar. It is a valid criticism, but it is only useful scientifically if one develops a new theory that has even better explanatory power, that encompasses the success of previous theories and adds to that success. Success means the ability to predict which sentences are well formed.
The more interesting debate is the origin of natural language grammar; whether it is conscious consensus, innate, or emergent. The "greco-roman grammatical tradition" clearly falls into the first category, which is in stark contrast to Chomsky's idea that human brains may have language specific structures, while the emergent hypothesis is more widely accepted these days. These debates are interesting, because it is possible that all of these ideas may have varying degrees of truth.
You have to be willing to think outside the box when discussing these big ideas in linguistics (indeed, in all science). Even if an idea might seem preposterous to you, it is useful to challenge your preconceptions of how the world works. An example is the Sapir-Whorf hypothesis that the structure of language affects a person's conceptualization of the world. Though it now lacks general acceptance, it still serves as an interesting counter to the axiom that language structure has no affect at all on cognition, and there are interesting experimental examples of the effect of linguistic categories on cognition.
I'd have to agree with you that the fanboys don't do anybody a favour. I'm sorry to hear that your experience was such a frustrating one, and I certainly don't think that people should feel guilty for using closed source software, particularly where they can see no viable choice.
Slashdot Mirror
... and in this case, sent with a one time pigeon
You would have preferred that no one oppose Germany's plans of occupying Europe?
"In Flanders Fields" was written during the Great War, not World War II.
Except that the basic research has been done, fusion has been demonstrated. Yes, there are still some significant materials and confinement hurdles to achieve a commercially viable system, but it is primarily a engineering challenge, not a basic research one.
You don't invest in money, whether it is fiat currency or bitcoin currency. You invest in things that are known to have long term desirable value. You may speculate on currency fluctuations (and futures, and so on), you might even do well out of it, but that can only work while there is liquidity in the system, while transactions are being made.
For bitcoin to have long term desirable value, it has to have a purpose. It's purpose is to make transactions, at the moment specifically catering to a desire for anonymity. However, in order for there to be transactions, there has to be both a buyer and a seller, and this can only happen if the currency is stable. In unstable currencies, all transactions cease (because either buyers or sellers stop trading, depending on the direction of the instability).
At the moment the bitcoin currency is relatively stable (allowing for the small size of the economy), as mining replaces the bitcoins that have been squirrelled away into 'investment' accounts. As mining becomes exponentially more difficult, the deflation will also increase exponentially. Initially, that will simply increase the value of a bitcoin. At some point though, either people will start to bail out when they see the end in sight (which happens when there aren't enough sellers in the system), or the satoshi will no longer be small enough...
There's no point in having a million dollars worth of bitcoins if you can't spend them on something you actually need or want.
Don't get me wrong, I like the idea of a peer based financial system, and I watch the bitcoin experiment with interest. It has technical merit, but I am not convinced of its long term stability. And stability is the key factor in a sustainable trade system.
It is a software implementation of OpenGL, but it now also provides the libGL glue to various hardware acceleration drivers. So it does have a role on most Xorg systems. An exception is the Nvidia proprietary infrastructure (which replaces large portions of the normal 3D graphics stack).
Actually, you can even do that too using Winelib. Might require a certain tendency to masochism.
Language boundaries are defined by mutual intelligibility of the communication system. This can be simplistic, but it provides a good first approximation that is testable. There are border cases (such as language chains), but on the whole it is a useful definition.
In comparison, dialect contours are defined in terms of specific language features. What speakers call a "dialect" is an identification, and while this may correspond roughly to collections of language features, it is really a sociolinguistic definition of language variety.
The notion of race is analogous to these sociolinguistic definitions, not to language; it is not defined by external factors, but by social ideas. There may be superficial features that are assumed to be associated with particular "races" (much as superficial language features are assumed to be associated with particular dialects), but these features are a poor definition of "race", because they are not clustered, and cross the boundaries of what people perceive as "race". In other words, "race" is a social construct.
It is the notion of species that is analogous to language. Species boundaries are defined by fertile offspring. Again, there are border cases, but it is testable.
anonymous "one" can argue that black is white and get killed on the next zebra crossing too
Define "won". And then try explaining it to a Vietnamese civilian who went through that war.
No.
I agree. Semantics (the relation of language to meaning) is important. I wasn't defending HP's misuse of the word 'memristor'.
The issue here isn't the imperfection of the HP device. It is a matter of semantics.
The 'memristor' was conceived as a term to describe a basic device where the change in flux is related to the change in charge.
What HP have produced is a device that substantially behaves like a memristor, if you are only measuring current and voltage at the terminals. That's useful if you want to build a memory device, since the behaviour is such that resistance will vary with the integral of the current through it.
However, the physics by which the HP device works is not a physics of memristance. For practical purposes, that may not matter; it is a simple device with useful properties. But terminology wise, it is memristance behaviour, not an unqualified memristor.
Equivalently, one can build an active circuit that uses a capacitor and a feedback loop to emulate an inductor. It isn't technically an inductor at all, but it does get called an "active inductor".
The advantage of the object oriented paradigm is not primarily that it makes programming easier or faster. It is the better support of separation between different components, which makes it possible to contain the complexity of large projects with multiple software engineers.
Of course, there are other ways of handling large projects (for example, there are examples of large projects written in C that control complexity by conventions about the separation of data and modules). But the object oriented paradigm is a common choice for large software engineering projects.
You might miss this when learning from a text book, since you are often only given small code examples and toy object hierarchies. But that extra 'overhead' around the defining of object abstraction pays off as the complexity increases. For many problems, thinking in terms of objects rather than instruction sequences can make the problem easier to solve.
Starting off with C and moving to C++ is not necessarily a good process, as you will not begin to learn to think in terms of objects; it is a completely different way of problem solving. Even for experienced programmers, the transition from C to C++ can be a six month process, not because of the extra language features, but because it requires a change in approach. Many don't stick at it long enough to realize the benefits.
The trade-off over speed is not an issue at all; for example, C++ is not significantly slower than C. Speed is affected far more by other choices; data structures and algorithms, memory localization, parallelism, and so on.
And you would also be aware that there are other paradigms as well, such as functional programming. These paradigms are not just "different tools for the job". They can have a radical impact on problem solving methods.
Your topic was whether nuclear weapons will keep 'non-fanatical' countries out of a war. My point is that you are overconfident of the rationality of the two countries that maintain the bulk of nuclear weapons. Woodrow Wilson taked about "the war to end war". Now you say that nuclear weapons are the weapons to end all major wars. Forgive my skepticism; I base this on past behaviour, not on suppositions about whether large states will or will not join a conflict. We are still over reliant on wise and considered decision making (such as the judgement call by Stanislav Petrov); I don't think we can take that short term stability for granted. If the assassination of a single person in Bosnia can lead to a world war, what do you imagine might happen if a nuclear weapon was used to murder an entire city?
Conflicts have been known to escalate beyond rationality in the past; World War I is a prime example.
Yes, for example, there were a number of anecdotes of MySQL databases using 100% CPU time, and the article mentions the similar Java/Cassandra problem. I suspect these two probably account for the majority of issues encountered.
http://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/
The reason that the command line survives is that it is a model of the way that humans communicate abstract concepts - primarily using language, not using pictures. Yes, there are plenty of examples where a picture is worth a thousand words. For many applications (such as one-off editing of a photograph) a GUI makes a lot of sense. But there's no need to rip out the language facility from the user interface!
If you were going to criticize the command line interface, it would be to criticize the poor "grammatical constructions" (the inconsistent syntax and quoting methods), and the poor "semantics" (difficult to remember option codes, hard to access manuals). But these are arguments for improving the command line interface, not for discarding it. The prime reason that puts people off using the command line interface is that there are no hints as to what to type next, no feedback. It is a problem we should address.
A graphical interface is quite poor for some things, for example "do this a thousand times". The problem isn't the "thousand times"; easy enough to have a GUI element that handles it. The problem is the denotation "this", an abstraction that is hard to visualize. At best, you represent "this" as a macro sequence of GUI actions, but that is only a single level of abstraction with no parameterization. A command line interface can handle such abstractions with ease.
While ground turbulence is going to detract from peak performance, in level flight helicopters do benefit from translational lift, which increases the weight capacity. On take off, you cannot achieve forward motion until you are off the ground; ground effect helps to gain ground clearance in order to start moving forward under heavy loads. Thus the maximum load can potentially be higher than can be maintained in a hover (not that I'm saying this is necessarily a desirable scenario). In mountainous terrain, the pilot may make use of a descent to gain the forward speed rather than ground effect.
Reminds me of an interesting case in the 1970s in Australia. Edward Ward shot a fisherman on the Murray riverbank near Echuca, and the body ended up half in the water. He was found guilty of murder in Victoria. But because the boundary wasn't well defined (the river itself belonged to NSW), there was a drawn out legal battle that eventually ended up in the High Court having to define the boundary more precisely. Ward didn't get a reprieve though, because he was retried in NSW and still got life imprisonment.
The implementation of the state machine is of less interest because it is finite. The aim of the exercise is to reduce the the notion of computability to a machine-like process. The most simple conception is that only one part of the machine is infinite and variable. That is why Turing needed to show how to implement a Universal Machine as a single Turing Machine, so that the transition table could be made fixed in size (and after that point, uninteresting in implementation). It would have been sufficient to posit a human reading a pencil and paper transition table and methodically applying the transitions to the tape; the important part is that the process is "mechanical" meaning without the involvement of creativity, not "mechanical" meaning that it can be realized in a mechanical form.
Of course, if you want to build a model of a Turing Machine, then the implementation does become more interesting, so I agree with you that this Lego model is only half of the puzzle.
Obviously they hadn't heard of Georg Cantor. He would have had no trouble representing an infinite matrix using an infinite list.
The Fujitsu press release is light on detail too.
blessed are the cheesemakers...
Chomsky's theories date back to the 1950s, and while they have their flaws, his exposition of transformational grammar was a sea-change in the study of syntax. You can't both at the same time claim that (a) he "didn't invent" anything, and (b) that he "did ruin several generations of thought on language and communication" with that thing that he didn't event.
You are also confused about the particular replicability of his generative grammars on computers; Chomsky's particular version of the generative grammars have proven less easy to implement in computerized natural language processing than some of the other more deterministic phrase structure grammars, and for many languages with free word order, dependency grammars have been a easier choice.
And the reality now is that a lot of NLP projects have given up on defined grammars and resorted to stochastic models; because for many applications people don't care about defining syntax at all (which requires time-consuming language study), they just care about outcomes. Unfortunately this has meant that success rates have plateaued after the initial quantum improvement, because while stochastic models are "relatively easy to mimic in computers", they don't always add insight into how human language works. "Doing science" when it comes to syntax involves more than just evaluating the social statistics of language use, it also includes modeling the generative power of human language.
It isn't enough to criticize the Euro-centric nature of transformational grammar. It is a valid criticism, but it is only useful scientifically if one develops a new theory that has even better explanatory power, that encompasses the success of previous theories and adds to that success. Success means the ability to predict which sentences are well formed.
The more interesting debate is the origin of natural language grammar; whether it is conscious consensus, innate, or emergent. The "greco-roman grammatical tradition" clearly falls into the first category, which is in stark contrast to Chomsky's idea that human brains may have language specific structures, while the emergent hypothesis is more widely accepted these days. These debates are interesting, because it is possible that all of these ideas may have varying degrees of truth.
You have to be willing to think outside the box when discussing these big ideas in linguistics (indeed, in all science). Even if an idea might seem preposterous to you, it is useful to challenge your preconceptions of how the world works. An example is the Sapir-Whorf hypothesis that the structure of language affects a person's conceptualization of the world. Though it now lacks general acceptance, it still serves as an interesting counter to the axiom that language structure has no affect at all on cognition, and there are interesting experimental examples of the effect of linguistic categories on cognition.
I'd have to agree with you that the fanboys don't do anybody a favour. I'm sorry to hear that your experience was such a frustrating one, and I certainly don't think that people should feel guilty for using closed source software, particularly where they can see no viable choice.