Well, actually the proper answer is good insulation, but that brings in it's own problems (air circulation and quality) and only works if you own the property to start with.
The right answer doesn't involve lots of on-going costs (i.e. energy input), but it *does* require a bunch of up-front investment. How to get from the current situation to the "right answer", however, isn't clear.
I think you think this was a targeted attack, but personally I really doubt that. I think it was a target of opportunity seized by some automated bot. Which doesn't mean you should think more kindly of those who released it.
OTOH, I wouldn't believe that 50,000 jobs story, except possibly during the process of construction. Foxconn is the company that's building automated plants in China to avoid high labor costs.
Sorry, but people talk to their phones, their cars, etc. all the time. Hell, they even talk to light switches "Why won't you turn on you stupid switch!".
It depends on exactly what you are after. Sedgewick has/had a few books called "Algorithms in C++/Pascal/??" that was decent light coverage. "Algorithms + Data Structures = Programs" by Wirth is pretty good, but I don't think it was ever translated out of Pascal. And the current modern approach is Google (I only recommend that one as a supplement).
P.S.: One of the Sedgewick books had several errors in the algorithms, so be sure you don't get the first edition.
Well...there are partial orderings where the order can only be determined between parts of the covered domain, but global consistency is a requirement. I can imagine cases where time at which something was noticed was blended with the value of what was noticed which could yield contradictory interpretations if you ignored the time, and various other permutations.
The GPs actual claim is, as you say, rubbish, but it may be a simplified abstraction of an underlying true statement. (Or he could be a troll.)
Introduction to Algorithms by Cormen et. al. is a good book and covers part of the same space.
I do agree that he uses MIX more than is needed, but it's necessary for a part of what he covers. For other parts C would be a superior substitute. And while I keep several works on algorithms on my shelves, and rarely turn to Knuth, we something isn't covered well elsewhere, that's where I turn.
Some of them *are* just like programmers. Others... well, be kind.
That said, all of the higher level languages tend to obscure computational complexity to the point where I can frequently only tell exactly which approach is better by measuring after writing the code in more than one way. Too much magic dust between the level at which I'm writing at and the level it compiles to. But I still think that to be a decent programmer you need to understand things like index registers, storage allocation, and probably accumulators, even though no current chip has them (at the assembler level...probably at the microcode level).
OTOH, if I'm working at the assembler level, then synchronizing thread data visibility is beyond me. (Well, so is most stuff. I haven't done assembler language programming on any modern chip. The last one was the Z80.)
But without the assembler background (MIX would count) you can't build a good mental model of C, and without a good mental model of a basic compiler language, you can't really understand a dynamically allocated vector (or array, depending on your language).
I'm not sure that starting at the top, Python/PHP/Ruby/Scratch/Logo/etc., and building your understanding down will ever work. I haven't seen any good examples. (OTOH, I've certainly seen examples of starting at assembler and then not being able to build up, so perhaps.)
It used to be said that a good programmer tried to learn a new language every year. But that was back when languages were both very different and small. Still, I'd recommend that any programmer work his way through some sort of assembler, C, Scheme, Erlang, and Java. C++ is too big to include. Ada and Eiffel would be good additions, but don't add anything really important. Smalltalk seems to be dieing out, but you should pick up the Scratch dialect, which shouldn't take as much as a week. If you want you could substitute Logo or Lisp for Scheme. The idea here isn't to really master the languages. Just to learn them enough to create something fairly simple, a bit beyond "Hello, World", but not necessarily as fancy as tic-tac-toe.
And anyone who does that counts as a "real programmer", even if they prefer to use Javascript or php...or even bash. Some others will also count as "real programmer", because being a "real programmer" is a matter in interest rather than skill or experience. An inclusive test isn't an exclusive test.
FWIW, I once taught someone to code in Fortran, and he went on to become a professional programmer, but he wasn't a "real programmer", because his interests were in business and astrology, not programming. He *was* a skilled programmer. He was quite intelligent. But that wasn't where his interests were, so he wasn't a "real programmer".
There haven't been that many stories, but a few stories have gotten a large amount of publicity, often repeatedly. And there's selection bias, too.
This doesn't prove that it's an incorrect assumption that Tesla drivers try to get the car to drive itself. Just a week ago I saw an electric wheelchair jay walking diagonally across a four lane boulevard (official speed limit 35 mph) while the driver of the wheelchair was busily engaged in texting on their phone. But notice that nobody EVER claimed THAT was safe behavior. So if anything that's evidence that renaming the "autopilot" wouldn't help;
I've got to disagree...though not totally. ISTM that overloaded operators need to be marked, rather than eliminated. I once suggested that overloaded operators be enclosed in pipe chars, e.g. |+|, but nearly any mark would do. And this be only used for operators. I also wanted to allow alternative symbols, names, etc. to be used for operators, but there I ran into the precedence problem
The language that's easy to read is the one you know well. I've used Python enough to think that it's easier to read than C or often C++ code that does the same thing. C's problems is indirections via multiple levels of pointers and macros. With C++ it is just that the language as a whole is too large, and I only know parts of it well, though it can include C's problems as well (but it doesn't need to).
I've looked at Nim a couple of times, most recently earlier this month. I didn't get much beyond looking, as I need various libraries as well as the basic language, but it did look interesting. If you only need one or two external libraries it might be worth your while to look at it more deeply than I did.
But I really doubt that their code generation averages as fast as decently hand-crafted code. But it may well be a lot faster to write.
You've got your definition, I've got mine. If you don't like mine, let's hear yours. (Mine would include not doing things that are clearly going to leave you in a situation that is worse, from your own evaluation, than the current situation, and which you have reason to know will have that result...unless, of course, all the alternatives would lead to even worse results.)
Well, we know of no fundamental law against it. I would claim that humans are NOT a counter-example existence proof, because to claim we're intelligent flies in the face of a large body of evidence to the contrary. So it may be impossible.
But it's clearly possible to get as close to intelligent as humans are, because there *IS* an existence proof. It may (hah!) require advanced nano-mechanics, but I really, really, doubt it.
That said, it doesn't take that much intelligence to be a threat to human existence. Just being able to issue the necessary commands with the required authority.
That said, while I do consider AIs to be an existential threat to humanity, I consider them LESS of a threat than the current political system. There's a reasonable chance that they'll have sufficient foresight and strong enough ethical constraints that they'll avoid the problem.
FWIW, we can't understand current deep-learning systems either. Different people understand different parts of them. Some understand fairly large parts, but nobody understands the complete program.
FWIW, that was even true with Sargon 40 years ago, and that wasn't an AI in any reasonable sense. It was basically an alpha-beta pruner and an evaluation function. And I understood a LOT of it, but not by any means all. (The source code was printed as a book for the Apple ][, but it naturally didn't include the systems routines, etc.)
People have limits on the complexity that they can understand. It varies slightly between people, but rarely exceeds certain bounds. I tend to call this our "stack depth" though that's clearly a poor analogy. But "working memory" can be measured (inexactly, it's true), and any idea too complex to be held in working memory can't be understood. We handle this by breaking it up into communicating modules, but the communication puts limits on the kinds of ideas we can handle. This is why when parallel programming I tend to use a simplified message-passing actor model. But some things can't be handled that way. If you doubt, try to imagine (visualize) a rotating tesseract. I have trouble even with a simple general quadratic curve and need to solve it and plot it out unless it's in one of a very few special forms.
You are making unreasonable assumptions about it's motivational basis. Here's a hint: It won't be analogous to any mammal, though it may be able to fake it so as to seem understandable.
That said, it *might* destroy all humans, possibly by causing us to destroy each other. Were I an AI, and had I decided upon that as an intermediate goal, I think I'd proceed by causing the social barriers against biological warfare to be reduced.
They have NOT re-established their reputation as a reputable technology company. That's going to take a LOT of work. Possibly as much as it took to build it in the first place, and they not only destroyed something that had taken decades to build over the course of a year, they repeated the offense multiple times by doing things like hiring people to put root kits into their devices, and then offering a "repair" that left you vulnerable to trivial attacks.
It's going to take lots of time and effort to repair their reputation. One good device that isn't yet known to be backdoored isn't going to do the job.
If they were looking at calcium channel opening, then I'd agree with you. They appear to be looking at things from a much more abstract level. And their results aren't proof, but certainly raise reasonable questions.
Don't believe the EULA limitations. A lot of them are just there as intimidation. Which terms are enforceable depend on your state, and local laws trump the EULA.
Judging by the summary, the rating is nearly worthless. E.g., Debian is a suite of about 1000 programs, so comparing it against any one other program is obviously silly. From the summary I can't decide whether they did something similar to the "Android OS", but they could well have. And anything that includes Flash will clearly have all the vulnerabilities that Flash does.
Now lets consider the difficulty of judging the seriousness of something give that we are only told it's a vulnerability...
If you are gambling on long term success, that's fair, but you should take the risk, not export it to someone else. Writeoffs exist because they benefit powerful people. But if you want to encourage some activity, it should be a separate piece of legislation, not a part of the tax code. I don't automatically oppose all things that writeoffs are supposed to accomplish, but I do oppose them being a part of the tax code.
"There Will Come Soft Rains", at least if you are referring to the Bradbury story, was not about automation. The automation was only the setting. It was about the dangers if over-killing war. IIRC he didn't even bother to specify exactly what the destructive agent was. (I believe I presumed that it was an omni-lethal disease, as I think the animal life survived, but that may just have been the poem rather than direct description.)
If you haven't read the story, do so. I found it quite beautiful, although melancholy.
It's already been happening. You don't notice this as long as the jobs are expanding faster than the automation makes the jobs redundant, but that doesn't continue forever.
The current mode of "replacement" is fancy tools that allow 3 programmers to do the work of 10 or more. (Just imagine that you still had to enter all your data on Hollerith cards.) More advanced languages also assist this. Imagine how many programmers it would take if all the web pages needed to be built in Fortran IV. But to a point decreasing the costs of doing a job results in the increase in the number of jobs. There are, however, limits. The number of programmers seems to me to have started decreasing during the 1970's, but SLOWLY. It picked up again for awhile as personal computers reduced the cost tremendously, but by around 2000 it was again dropping. This is, of course, just based on personal observations. One datta point isn't extremely useful, but it's consistent with the posts on slashdot. Of course the off-shoring of jobs isn't new, but it did increase, and may still be increasing (I'm now retired, so I can no longer observe directly), but the purpose of this was to reduce costs, and if another approach to reducing costs is more effective, it will be adopted instead. And there are signs that the trend is slowing...which implies that some more effective way of reducing expenses is being adopted. I don't think that the current trend is due to actual AI, yet. But it will be.
Slashdot Mirror
Well, actually the proper answer is good insulation, but that brings in it's own problems (air circulation and quality) and only works if you own the property to start with.
The right answer doesn't involve lots of on-going costs (i.e. energy input), but it *does* require a bunch of up-front investment. How to get from the current situation to the "right answer", however, isn't clear.
I think you think this was a targeted attack, but personally I really doubt that. I think it was a target of opportunity seized by some automated bot. Which doesn't mean you should think more kindly of those who released it.
Depends on what he's successful at.
OTOH, I wouldn't believe that 50,000 jobs story, except possibly during the process of construction. Foxconn is the company that's building automated plants in China to avoid high labor costs.
Sorry, but people talk to their phones, their cars, etc. all the time. Hell, they even talk to light switches "Why won't you turn on you stupid switch!".
It depends on exactly what you are after. Sedgewick has/had a few books called "Algorithms in C++/Pascal/??" that was decent light coverage. "Algorithms + Data Structures = Programs" by Wirth is pretty good, but I don't think it was ever translated out of Pascal. And the current modern approach is Google (I only recommend that one as a supplement).
P.S.: One of the Sedgewick books had several errors in the algorithms, so be sure you don't get the first edition.
Well...there are partial orderings where the order can only be determined between parts of the covered domain, but global consistency is a requirement. I can imagine cases where time at which something was noticed was blended with the value of what was noticed which could yield contradictory interpretations if you ignored the time, and various other permutations.
The GPs actual claim is, as you say, rubbish, but it may be a simplified abstraction of an underlying true statement. (Or he could be a troll.)
Introduction to Algorithms by Cormen et. al. is a good book and covers part of the same space.
I do agree that he uses MIX more than is needed, but it's necessary for a part of what he covers. For other parts C would be a superior substitute. And while I keep several works on algorithms on my shelves, and rarely turn to Knuth, we something isn't covered well elsewhere, that's where I turn.
Some of them *are* just like programmers. Others... well, be kind.
That said, all of the higher level languages tend to obscure computational complexity to the point where I can frequently only tell exactly which approach is better by measuring after writing the code in more than one way. Too much magic dust between the level at which I'm writing at and the level it compiles to. But I still think that to be a decent programmer you need to understand things like index registers, storage allocation, and probably accumulators, even though no current chip has them (at the assembler level...probably at the microcode level).
OTOH, if I'm working at the assembler level, then synchronizing thread data visibility is beyond me. (Well, so is most stuff. I haven't done assembler language programming on any modern chip. The last one was the Z80.)
But without the assembler background (MIX would count) you can't build a good mental model of C, and without a good mental model of a basic compiler language, you can't really understand a dynamically allocated vector (or array, depending on your language).
I'm not sure that starting at the top, Python/PHP/Ruby/Scratch/Logo/etc., and building your understanding down will ever work. I haven't seen any good examples. (OTOH, I've certainly seen examples of starting at assembler and then not being able to build up, so perhaps.)
It used to be said that a good programmer tried to learn a new language every year. But that was back when languages were both very different and small. Still, I'd recommend that any programmer work his way through some sort of assembler, C, Scheme, Erlang, and Java. C++ is too big to include. Ada and Eiffel would be good additions, but don't add anything really important. Smalltalk seems to be dieing out, but you should pick up the Scratch dialect, which shouldn't take as much as a week. If you want you could substitute Logo or Lisp for Scheme. The idea here isn't to really master the languages. Just to learn them enough to create something fairly simple, a bit beyond "Hello, World", but not necessarily as fancy as tic-tac-toe.
And anyone who does that counts as a "real programmer", even if they prefer to use Javascript or php...or even bash. Some others will also count as "real programmer", because being a "real programmer" is a matter in interest rather than skill or experience. An inclusive test isn't an exclusive test.
FWIW, I once taught someone to code in Fortran, and he went on to become a professional programmer, but he wasn't a "real programmer", because his interests were in business and astrology, not programming. He *was* a skilled programmer. He was quite intelligent. But that wasn't where his interests were, so he wasn't a "real programmer".
I think it's more selection bias on the part of the news media/sources.
There haven't been that many stories, but a few stories have gotten a large amount of publicity, often repeatedly. And there's selection bias, too.
This doesn't prove that it's an incorrect assumption that Tesla drivers try to get the car to drive itself. Just a week ago I saw an electric wheelchair jay walking diagonally across a four lane boulevard (official speed limit 35 mph) while the driver of the wheelchair was busily engaged in texting on their phone. But notice that nobody EVER claimed THAT was safe behavior. So if anything that's evidence that renaming the "autopilot" wouldn't help;
I've got to disagree...though not totally. ISTM that overloaded operators need to be marked, rather than eliminated. I once suggested that overloaded operators be enclosed in pipe chars, e.g. |+|, but nearly any mark would do. And this be only used for operators. I also wanted to allow alternative symbols, names, etc. to be used for operators, but there I ran into the precedence problem
The language that's easy to read is the one you know well. I've used Python enough to think that it's easier to read than C or often C++ code that does the same thing. C's problems is indirections via multiple levels of pointers and macros. With C++ it is just that the language as a whole is too large, and I only know parts of it well, though it can include C's problems as well (but it doesn't need to).
I've looked at Nim a couple of times, most recently earlier this month. I didn't get much beyond looking, as I need various libraries as well as the basic language, but it did look interesting. If you only need one or two external libraries it might be worth your while to look at it more deeply than I did.
But I really doubt that their code generation averages as fast as decently hand-crafted code. But it may well be a lot faster to write.
You've got your definition, I've got mine. If you don't like mine, let's hear yours. (Mine would include not doing things that are clearly going to leave you in a situation that is worse, from your own evaluation, than the current situation, and which you have reason to know will have that result...unless, of course, all the alternatives would lead to even worse results.)
Well, we know of no fundamental law against it. I would claim that humans are NOT a counter-example existence proof, because to claim we're intelligent flies in the face of a large body of evidence to the contrary. So it may be impossible.
But it's clearly possible to get as close to intelligent as humans are, because there *IS* an existence proof. It may (hah!) require advanced nano-mechanics, but I really, really, doubt it.
That said, it doesn't take that much intelligence to be a threat to human existence. Just being able to issue the necessary commands with the required authority.
That said, while I do consider AIs to be an existential threat to humanity, I consider them LESS of a threat than the current political system. There's a reasonable chance that they'll have sufficient foresight and strong enough ethical constraints that they'll avoid the problem.
FWIW, we can't understand current deep-learning systems either. Different people understand different parts of them. Some understand fairly large parts, but nobody understands the complete program.
FWIW, that was even true with Sargon 40 years ago, and that wasn't an AI in any reasonable sense. It was basically an alpha-beta pruner and an evaluation function. And I understood a LOT of it, but not by any means all. (The source code was printed as a book for the Apple ][, but it naturally didn't include the systems routines, etc.)
People have limits on the complexity that they can understand. It varies slightly between people, but rarely exceeds certain bounds. I tend to call this our "stack depth" though that's clearly a poor analogy. But "working memory" can be measured (inexactly, it's true), and any idea too complex to be held in working memory can't be understood. We handle this by breaking it up into communicating modules, but the communication puts limits on the kinds of ideas we can handle. This is why when parallel programming I tend to use a simplified message-passing actor model. But some things can't be handled that way. If you doubt, try to imagine (visualize) a rotating tesseract. I have trouble even with a simple general quadratic curve and need to solve it and plot it out unless it's in one of a very few special forms.
You are making unreasonable assumptions about it's motivational basis. Here's a hint: It won't be analogous to any mammal, though it may be able to fake it so as to seem understandable.
That said, it *might* destroy all humans, possibly by causing us to destroy each other. Were I an AI, and had I decided upon that as an intermediate goal, I think I'd proceed by causing the social barriers against biological warfare to be reduced.
They have NOT re-established their reputation as a reputable technology company. That's going to take a LOT of work. Possibly as much as it took to build it in the first place, and they not only destroyed something that had taken decades to build over the course of a year, they repeated the offense multiple times by doing things like hiring people to put root kits into their devices, and then offering a "repair" that left you vulnerable to trivial attacks.
It's going to take lots of time and effort to repair their reputation. One good device that isn't yet known to be backdoored isn't going to do the job.
If they were looking at calcium channel opening, then I'd agree with you. They appear to be looking at things from a much more abstract level. And their results aren't proof, but certainly raise reasonable questions.
Don't believe the EULA limitations. A lot of them are just there as intimidation. Which terms are enforceable depend on your state, and local laws trump the EULA.
Judging by the summary, the rating is nearly worthless. E.g., Debian is a suite of about 1000 programs, so comparing it against any one other program is obviously silly. From the summary I can't decide whether they did something similar to the "Android OS", but they could well have. And anything that includes Flash will clearly have all the vulnerabilities that Flash does.
Now lets consider the difficulty of judging the seriousness of something give that we are only told it's a vulnerability...
If you are gambling on long term success, that's fair, but you should take the risk, not export it to someone else. Writeoffs exist because they benefit powerful people. But if you want to encourage some activity, it should be a separate piece of legislation, not a part of the tax code. I don't automatically oppose all things that writeoffs are supposed to accomplish, but I do oppose them being a part of the tax code.
If that's what they were doing, they wouldn't need to rent Watson.
"There Will Come Soft Rains", at least if you are referring to the Bradbury story, was not about automation. The automation was only the setting. It was about the dangers if over-killing war. IIRC he didn't even bother to specify exactly what the destructive agent was. (I believe I presumed that it was an omni-lethal disease, as I think the animal life survived, but that may just have been the poem rather than direct description.)
If you haven't read the story, do so. I found it quite beautiful, although melancholy.
It's already been happening. You don't notice this as long as the jobs are expanding faster than the automation makes the jobs redundant, but that doesn't continue forever.
The current mode of "replacement" is fancy tools that allow 3 programmers to do the work of 10 or more. (Just imagine that you still had to enter all your data on Hollerith cards.) More advanced languages also assist this. Imagine how many programmers it would take if all the web pages needed to be built in Fortran IV. But to a point decreasing the costs of doing a job results in the increase in the number of jobs. There are, however, limits. The number of programmers seems to me to have started decreasing during the 1970's, but SLOWLY. It picked up again for awhile as personal computers reduced the cost tremendously, but by around 2000 it was again dropping. This is, of course, just based on personal observations. One datta point isn't extremely useful, but it's consistent with the posts on slashdot. Of course the off-shoring of jobs isn't new, but it did increase, and may still be increasing (I'm now retired, so I can no longer observe directly), but the purpose of this was to reduce costs, and if another approach to reducing costs is more effective, it will be adopted instead. And there are signs that the trend is slowing...which implies that some more effective way of reducing expenses is being adopted. I don't think that the current trend is due to actual AI, yet. But it will be.