Can you compile C++ down small enough to use in embedded devices or does C++ still pull in libraries that are not needed or too big? My guess is you can exclude the libraries that you do not need, correct? (Not trying to start anyone flaming, I honestly do NOT know.)
Generally any C++ on embedded devices will be a subset. Forget about the STL...
Take optimization problems - there is an insane amount of applications that we currently don't think of since, like i said before, we've resigned our hopes in being able to tackle those.
Because they tend to be NP-complete (or even PSPACE-complete); even massively parallel machines only reduce complexity by a constant factor. So approximate algorithms are going to continue to be the way to go there.
It is my understanding that this data was already obtainable in the first place.
This is true. But the easier it is to obtain datasets like these, the easier it is for anyone to do data mining and correlate the public (presumably non-identified) datasets with any private data they do happen to have.
This isn't rational. There are more choices in this continuum than "shoot him dead" or "he gets away with no punishment". Why do you assume that he'll escape entirely if you don't personally kill him where he stands?
Because, frankly, that's the way to bet. The police rarely catch car thieves, except by accident.
The U-7 rate was discontinued, but the current U-6 includes everything the old U-7 did, plus "marginally attached" workers (who were not included in the old U-7) rate.
Old U-5 = official rate Old U-6 = old U-5 - 1/2 unemployed seeking work part time + 1/2 working part time but desiring full time Old U-7 = old U-6 + discouraged workers (those wanting work but not seeking it because they figured it was a lost cause)
New U-3 = official rate = same definition as old U-5 New U-4 = new U-3 + discouraged workers New U-5 = new U-4 + "marginally attached" workers, which is those wanting work but not seeking it for reasons besides being "discouraged" New U-6 = new U-6 + those working part time but desiring full-time
Note the new U-6 treats the "underemployed" and the unemployed seeking part time jobs the same as the full-time unemployed, no weighting.
Contracts don't have to be signed. If you cash a check, and the university says the reason they gave you the money was to buy the rights, you're going to have to prove otherwise.
In many things, yes, In copyright, no. Copyright can only be conveyed explicitly; see 17 USC 204(a).
World's highest per-student spending rates, and yet our teachers can't afford to make photocopies. How the hell did we get here?
Siphon education money off to nonproductive uses. Poormouth about lack of education money for necessities. Obtain more money. Repeat until taxpayers balk. Paint balking taxpayers as evil skinflints out to destroy public education. Obtain more money. Repeat ad infinitum.
Nothing does more to raise the quality of life than public education.
Nonsense. Enclosed sewers and sewer treatment come immediately to mind.
Just try, once, to imagine what life would be like if all those millions of people who can't afford to get educated never learn basic literacy and arithmetic?
It'd be like living in a major city in the US... today. Because today's public education often just doesn't work.
And yet, The UK and Europe have far worse "wire-tapping" sorts of things than the US. But it's not in vogue to complain about it anywhere but in the US, it seems.
That's because if you complain about it in the UK they slap an ASBO on you.
Dijkstra was a genius and made many contributions to Comp. Sci. But his suggestion that a program (really a program design) should be accompanied by a formal proof has problems at both ends of the development cycle: how do you prove that the formal specification is what the customer wanted, and how do you prove that the code actually implements the design?
When I was in the CS curriculum in the University of Maryland shortly after the publication of this paper, one of the mandatory freshman CS courses took this approach.
The fatal problem of the approach quickly became apparent: the formal specification had to be as detailed as the program, the process of proving the program met the specification was just as complex _and error-prone_ as the process of writing the program in the first place.
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
Documentation may be necessary; certainly documenting interfaces is, and some amount of internals documentation is prudent. But no amount of documentation will make poor code anything but poor. Nor will any lack of documentation make excellent code poor; it merely makes it undocumented.
Doing that requires submission to the processes needed by others and being both courageous and disciplined enough to do so.
Courageous submission... wasn't that one of the Ingsoc slogans?
The appropriate question to ask is would a thorough code review of the Mars Climate Orbiter software have prevented its loss? The problem was one of units (metric vs. English) which means the code on either side of the interface was absolutely correct. Only a live person looking at both pieces of code could realize that one piece of code used metric units while the other used English units.
If the procedures were followed, there would have been an Interface Control Document (ICD) which would have specified the interface, including the units. The ICD requirements would have fed into the Software Design Documents (SDDs) for each side of the interface. These requirements would have been traced back from the SDDs to the ICD and ultimately back to the System/Subsystem Design Document (SSDD), via the requirements traceability matrix. Theoretically, all this paperwork would have prevented exactly that sort of error.
In actuality, of course, the process of verifying software requirements is error prone as well. Not to mention extremely tedious.
(it's been a long time since I suffered through government software design, so some of the TLAs above may be wrong or superceded. But you get the idea).
At the big company I worked at, someone added some features to code that I wrote. It broke my code. I wanted to go in and fix it. Why not? I knew how it worked. I couldn't without a defect written by a tester.
Annoying, but easy to handle. Testers love to find bugs, whether it be for the joy of crushing a young programmer's spirit, or for the look of fear in the eyes of the product manager as the release date approaches. Point a tester towards the bug, and he'll go right ahead and write a defect, possibly cackling evilly as he does so.
Excellence can be determined in various ways, often through documentation, the great allergen of programmers. If you can't explain it, it isn't really done.
Wrong. Once the program is written, it has been explained in detail to the party which will be executing it. Namely, the machine.
If you want to determine the excellence of a program, you have to examine the program -- if not the code, then its behavior. The documentation tells you little. If you just want a check box for your corporate "excellence" program, however, go right ahead and examine the documentation.
Slashdot Mirror
Nope. TroopDRM ensures there's only one download for every uploaded soldier. But the Chinese have a LOT of soldiers to upload...
Generally any C++ on embedded devices will be a subset. Forget about the STL...
Googling 'tail recursion' produces a page which says at the end "Did you mean 'tail recursion'"?
Either that, or it's because the lambda calculus has sent more than one geek running screaming off into the night.
Because they tend to be NP-complete (or even PSPACE-complete); even massively parallel machines only reduce complexity by a constant factor. So approximate algorithms are going to continue to be the way to go there.
This is true. But the easier it is to obtain datasets like these, the easier it is for anyone to do data mining and correlate the public (presumably non-identified) datasets with any private data they do happen to have.
Because, frankly, that's the way to bet. The police rarely catch car thieves, except by accident.
The U-7 rate was discontinued, but the current U-6 includes everything the old U-7 did, plus "marginally attached" workers (who were not included in the old U-7) rate.
Old U-5 = official rate
Old U-6 = old U-5 - 1/2 unemployed seeking work part time + 1/2 working part time but desiring full time
Old U-7 = old U-6 + discouraged workers (those wanting work but not seeking it because they figured it was a lost cause)
New U-3 = official rate = same definition as old U-5
New U-4 = new U-3 + discouraged workers
New U-5 = new U-4 + "marginally attached" workers, which is those wanting work but not seeking it for reasons besides being "discouraged"
New U-6 = new U-6 + those working part time but desiring full-time
Note the new U-6 treats the "underemployed" and the unemployed seeking part time jobs the same as the full-time unemployed, no weighting.
U7? What's that, the percentage of people who aren't employed in jobs which allow them to have McMansions and multiple SUVs?
The BLS discontinued the official U-7 rate in 1994.
U-6 includes those employed part-time who say they'd rather be employed full-time, which is the big difference.
Yeah, well, the US had some bad experience with plastic pipe, namely polybutylene. Makes the code people skittish.
Just charge up _all_ the copper to at least 50KV. Copper theft will become self-punishing. However, taking a shower will get quite risky.
In many things, yes, In copyright, no. Copyright can only be conveyed explicitly; see 17 USC 204(a).
Siphon education money off to nonproductive uses. Poormouth about lack of education money for necessities. Obtain more money. Repeat until taxpayers balk. Paint balking taxpayers as evil skinflints out to destroy public education. Obtain more money. Repeat ad infinitum.
Or Microsoft High School??
Nonsense. Enclosed sewers and sewer treatment come immediately to mind.
It'd be like living in a major city in the US... today. Because today's public education often just doesn't work.
That's because if you complain about it in the UK they slap an ASBO on you.
Leaving the 419 scams, eBay fraud, phishing for financial details, and violating the MySpace TOS all lost in the noise.
When I was in the CS curriculum in the University of Maryland shortly after the publication of this paper, one of the mandatory freshman CS courses took this approach.
The fatal problem of the approach quickly became apparent: the formal specification had to be as detailed as the program, the process of proving the program met the specification was just as complex _and error-prone_ as the process of writing the program in the first place.
You have been trolled (by Dijkstra).
I don't think I really understand what Dijkstra is getting at here. Can someone explain it to me with a car analogy?
Documentation may be necessary; certainly documenting interfaces is, and some amount of internals documentation is prudent. But no amount of documentation will make poor code anything but poor. Nor will any lack of documentation make excellent code poor; it merely makes it undocumented.
Courageous submission... wasn't that one of the Ingsoc slogans?
If the procedures were followed, there would have been an Interface Control Document (ICD) which would have specified the interface, including the units. The ICD requirements would have fed into the Software Design Documents (SDDs) for each side of the interface. These requirements would have been traced back from the SDDs to the ICD and ultimately back to the System/Subsystem Design Document (SSDD), via the requirements traceability matrix. Theoretically, all this paperwork would have prevented exactly that sort of error.
In actuality, of course, the process of verifying software requirements is error prone as well. Not to mention extremely tedious.
(it's been a long time since I suffered through government software design, so some of the TLAs above may be wrong or superceded. But you get the idea).
Annoying, but easy to handle. Testers love to find bugs, whether it be for the joy of crushing a young programmer's spirit, or for the look of fear in the eyes of the product manager as the release date approaches. Point a tester towards the bug, and he'll go right ahead and write a defect, possibly cackling evilly as he does so.
Wrong. Once the program is written, it has been explained in detail to the party which will be executing it. Namely, the machine.
If you want to determine the excellence of a program, you have to examine the program -- if not the code, then its behavior. The documentation tells you little. If you just want a check box for your corporate "excellence" program, however, go right ahead and examine the documentation.
Can't, or don't want to? Perhaps people would rather die fat than live while constantly denying themselves the foods they want.