You need to do a little more research into corporations and their habits in the 19th and early 20th centuries. I'm not saying that this is necessarily comparable to those days, but regulation of various sorts, eg to limit the influence professional scalpers can have, is not necessarily a bad thing.
People would scan and post their checks online for bragging rights. Unscrupulous individuals would then grab those images and use the routing/account numbers from them to steal money from Knuth.
He'll still send you the money if you really want it, but mostly he sends out fakes now to avoid that sort of problem. Since most people really just wanted the bragging rights anyway, it's not a big deal.
They didn't have a choice in the matter. AT&T was the only one willing to let them do what they wanted with the phone, and without that freedom it wouldn't have been the iPhone. Now that it has completely changed the direction for smartphones, everyone's willing to play ball, but that exclusivity was almost a requirement early on.
Why don't they then just quit? I mean, you can hunt carrot only for so long before realizing that, yep, i am hunting carrot and i will always be hunting carrot because that is how company turns profit.
They generally don't quit for one of (or a combination of) a few reasons:
1) They've already invested a lot of time into a character, and they don't want to throw that away. 2) They're playing primarily for social interactions and the "grind" is mostly something to do while hanging out with friends, so they don't mind it. 3) They're playing for the end-game raiding, which for many people *does* provide enough enjoyment to balance out any grind. 4) They're playing for the PvP, and they enjoy that enough to balance out a grind. 5) Hope springs eternal, and they suffer through a current grind because looking toward or getting that next shiny really is that much of a reward to them.
I've personally experienced all of those at times (1 a little less so), and I've definitely seen them in people I've played with (I don't play MMOs anymore).
Getting to 40 in Warhammer was fun... the first time. Unfortunately, the level 40 content was simply painfully bad, both PvE and PvP, and after the first wave it turned into more of a grind to get a new character up to 40. I hear the max-level stuff is better now (and they certainly keep trying to improve it), but that game had some of the worst end-game PvE and itemization I've ever seen, and the city siege system was great in theory but failed in practice in its first incarnations.
This article relates to the publishing of the *results* of the experiment announced in the first article. This is not (for once) a dup. Hence the "compiled over the past few months" bit in the summary.
Strategically deploying paint flecks is a *lot* harder to do than you might think. Unpowered intercepts on the sort of trajectory that would matter for an item that small would require truly amazing knowledge of spacecraft disturbances, not to mention precise knowledge of starting position and velocity.
Everything is harder in space than people outside the industry like to think it is.
No; then it became the finder's duty to turn the item over to the police. Only after a subsequent period would it actually become abandoned property to which the finder would have a right.
The finder stole it by failing to turn it over to the police and instead selling it along. It was lost property until that point; then it was stolen property.
I don't think the GP is upset at *Intel* in this regard; I think it's more a perfectly realistic consumer complaint: "I wish there were more competition in this space because that would be better for me as the consumer." AMD dropped the ball pretty badly after a very strong run with earlier Athalons. It'd be great to see them get back into the game and really help push things along again.
STK was probably used for visualization of trajectories; I'm pretty sure it wasn't used to actually create them, though. My guess is a lot of computer time with custom optimization code.
Also, I imagine it has more to do with simply getting close enough to Titan to slingshot off it than it has to do with the lagrange points; those are more useful if you *don't* want to move than if you *do*.
This is disingenuous. At the time when someone begins using a new device, they can be expected to have a certain set of knowledge and familiarity with certain other devices. Within that context, the new device could very well be "intuitive" in that the functions are naturally discovered and do not require that the user "re-think" the processes in order to accomplish a goal.
... or blame Microsoft or the handset manufacturers for not pushing the carriers for this. Apple manages to release fairly regular OS updates for the iPhone, and AT&T seems happy to re-validate the new software; Microsoft, at least, should surely have enough clout to manage the same.
I'm not saying the carriers don't have some responsibility, but they're not the only ones at fault here.
Just head to http://www.oracle.com/technology/software/index.html and grab the standard edition. The license for it allows for development against it, with some expected caveats: 1 download = 1 person, you can only use it for development (ie, you have to buy a license the moment you start using your app for anything other than testing), and you can only install it on one server.
You *do* have to buy a license if you want to test more complex oracle deployments, though, it seems.
Its handling of null and the empty string is incomprehensible and useless.
The empty string is, AFAIK, only handled in a screwy fashion in MySQL. I know that at least in PostgreSQL it's completely sane.
To this you add another component that's always an issue: the entirely haphazard way in which relational databases are implemented on most operating systems, whereby the DBMS is another application, that manages its own files, and needs to be coached with kind words and a happy smile in order to get anything done. Does your app use a database for something back-endy, like, for example, MythTV does for its settings and lists of channels and TV programs? Well, either forget it, or be prepared to put your users through hell as they have to ensure that the entirely separate DBMS is installed and that usernames and passwords are set up for your application's use.
This pretty much completely ignores the many embedded SQL dbs out there, starting with SQLite and moving up.
Because SQL sucks. It just sucks less than anything else designed to do the same thing.
As someone who writes a lot of SQL, I've actually really got to disagree here. Thinking in SQL is not the same as thinking in other programming languages, but it's actually very straightforward for what it does, especially if you actually have some set logic background and can therefore reason out what's going on. I think the only bits that start to get hairy are the more recent additions- recursive queries, for instance.
The biggest issue I see people have with SQL is thinking that they know more than the DB. When you back up a step and maintain a sufficient abstraction, the SQL pretty much just falls into place.
You take thousands of temperature readings over hundreds of years and come up with trends and that is not statistics?
No. It's data.
Past trends in data are not being extrapolated from to provide evidence directly for global warming. Instead, that data is being used to generate and validate models and theories on how the climate reacts to various changes; those models are then being used to make predictions. The statistics is only really used in a first pass at the data to remove any data bias, and then at the end to determine confidence intervals for the model outputs. Most of the work is a whole pile of differential equations.
Actually, one of the most dangerous uses of statistics is exactly predicting with them inappropriately. Curve fitting is especially prone to this error- attempting to make any predictions outside of the central mass of the points used to *produce* the curve is completely bogus, and yet people do it all the time.
I think this is largely a function of how OOP is taught- including the languages used to teach it. Too many people start with Java and its "everything is an object! but they're not all first-class objects! and we're going to try to hide it all from you even though you have to know the details anyway!" design principles instead of a language that either a) cleanly mixes OOP in with procedures *not* tied to objects, or b) is a fully OOP-supportive language in which everything really is a first-class object.
Instead we get "Java is OOP, C is not" when in truth you can easily do non-OOP programming in Java and OOP programming in pure C (and, as you pointed out, a lot of C from quite a ways back shows a lot of the features of OOP programming).
From my perspective, this is actually the correct prioritization- did anyone not know by now that Windows 7 has been very well received and is selling well? And, given that, it overtaking OS X in market share is more than a little obvious- if it *hadn't*, it'd be newsworthy.
Tab handling can be a fairly acrimonious debate among developers, though, so a change to one of the major tools out there for writing code that impacts that debate is, in fact, quite interesting.
There are a lot of purely compute-bound applications (think simulations of various sorts, etc) for which the algorithmic optimizations have already been done- but it's still worth going for the last few percent of performance from "instruction fiddling". As another poster said: if your app runs for weeks at a time, 1% improvement becomes significant in terms of time saved- and throwing more hardware at the problem isn't always feasible.
Slashdot Mirror
You need to do a little more research into corporations and their habits in the 19th and early 20th centuries. I'm not saying that this is necessarily comparable to those days, but regulation of various sorts, eg to limit the influence professional scalpers can have, is not necessarily a bad thing.
Oh, Apple has lots of freedom. They just don't pass most of that freedom on to their users. I was talking about Apple's freedom in my post, though.
People would scan and post their checks online for bragging rights. Unscrupulous individuals would then grab those images and use the routing/account numbers from them to steal money from Knuth.
He'll still send you the money if you really want it, but mostly he sends out fakes now to avoid that sort of problem. Since most people really just wanted the bragging rights anyway, it's not a big deal.
They didn't have a choice in the matter. AT&T was the only one willing to let them do what they wanted with the phone, and without that freedom it wouldn't have been the iPhone. Now that it has completely changed the direction for smartphones, everyone's willing to play ball, but that exclusivity was almost a requirement early on.
Why don't they then just quit? I mean, you can hunt carrot only for so long before realizing that, yep, i am hunting carrot and i will always be hunting carrot because that is how company turns profit.
They generally don't quit for one of (or a combination of) a few reasons:
1) They've already invested a lot of time into a character, and they don't want to throw that away.
2) They're playing primarily for social interactions and the "grind" is mostly something to do while hanging out with friends, so they don't mind it.
3) They're playing for the end-game raiding, which for many people *does* provide enough enjoyment to balance out any grind.
4) They're playing for the PvP, and they enjoy that enough to balance out a grind.
5) Hope springs eternal, and they suffer through a current grind because looking toward or getting that next shiny really is that much of a reward to them.
I've personally experienced all of those at times (1 a little less so), and I've definitely seen them in people I've played with (I don't play MMOs anymore).
Getting to 40 in Warhammer was fun... the first time. Unfortunately, the level 40 content was simply painfully bad, both PvE and PvP, and after the first wave it turned into more of a grind to get a new character up to 40. I hear the max-level stuff is better now (and they certainly keep trying to improve it), but that game had some of the worst end-game PvE and itemization I've ever seen, and the city siege system was great in theory but failed in practice in its first incarnations.
This article relates to the publishing of the *results* of the experiment announced in the first article. This is not (for once) a dup. Hence the "compiled over the past few months" bit in the summary.
Strategically deploying paint flecks is a *lot* harder to do than you might think. Unpowered intercepts on the sort of trajectory that would matter for an item that small would require truly amazing knowledge of spacecraft disturbances, not to mention precise knowledge of starting position and velocity.
Everything is harder in space than people outside the industry like to think it is.
No; then it became the finder's duty to turn the item over to the police. Only after a subsequent period would it actually become abandoned property to which the finder would have a right.
The finder stole it by failing to turn it over to the police and instead selling it along. It was lost property until that point; then it was stolen property.
I don't think the GP is upset at *Intel* in this regard; I think it's more a perfectly realistic consumer complaint: "I wish there were more competition in this space because that would be better for me as the consumer." AMD dropped the ball pretty badly after a very strong run with earlier Athalons. It'd be great to see them get back into the game and really help push things along again.
STK was probably used for visualization of trajectories; I'm pretty sure it wasn't used to actually create them, though. My guess is a lot of computer time with custom optimization code.
Also, I imagine it has more to do with simply getting close enough to Titan to slingshot off it than it has to do with the lagrange points; those are more useful if you *don't* want to move than if you *do*.
This is disingenuous. At the time when someone begins using a new device, they can be expected to have a certain set of knowledge and familiarity with certain other devices. Within that context, the new device could very well be "intuitive" in that the functions are naturally discovered and do not require that the user "re-think" the processes in order to accomplish a goal.
... or blame Microsoft or the handset manufacturers for not pushing the carriers for this. Apple manages to release fairly regular OS updates for the iPhone, and AT&T seems happy to re-validate the new software; Microsoft, at least, should surely have enough clout to manage the same.
I'm not saying the carriers don't have some responsibility, but they're not the only ones at fault here.
Just head to http://www.oracle.com/technology/software/index.html and grab the standard edition. The license for it allows for development against it, with some expected caveats: 1 download = 1 person, you can only use it for development (ie, you have to buy a license the moment you start using your app for anything other than testing), and you can only install it on one server.
You *do* have to buy a license if you want to test more complex oracle deployments, though, it seems.
Its handling of null and the empty string is incomprehensible and useless.
The empty string is, AFAIK, only handled in a screwy fashion in MySQL. I know that at least in PostgreSQL it's completely sane.
To this you add another component that's always an issue: the entirely haphazard way in which relational databases are implemented on most operating systems, whereby the DBMS is another application, that manages its own files, and needs to be coached with kind words and a happy smile in order to get anything done. Does your app use a database for something back-endy, like, for example, MythTV does for its settings and lists of channels and TV programs? Well, either forget it, or be prepared to put your users through hell as they have to ensure that the entirely separate DBMS is installed and that usernames and passwords are set up for your application's use.
This pretty much completely ignores the many embedded SQL dbs out there, starting with SQLite and moving up.
Because SQL sucks. It just sucks less than anything else designed to do the same thing.
As someone who writes a lot of SQL, I've actually really got to disagree here. Thinking in SQL is not the same as thinking in other programming languages, but it's actually very straightforward for what it does, especially if you actually have some set logic background and can therefore reason out what's going on. I think the only bits that start to get hairy are the more recent additions- recursive queries, for instance.
The biggest issue I see people have with SQL is thinking that they know more than the DB. When you back up a step and maintain a sufficient abstraction, the SQL pretty much just falls into place.
Yes. You can download oracle to develop against for free, in fact; I recently had to do it myself.
You take thousands of temperature readings over hundreds of years and come up with trends and that is not statistics?
No. It's data.
Past trends in data are not being extrapolated from to provide evidence directly for global warming. Instead, that data is being used to generate and validate models and theories on how the climate reacts to various changes; those models are then being used to make predictions. The statistics is only really used in a first pass at the data to remove any data bias, and then at the end to determine confidence intervals for the model outputs. Most of the work is a whole pile of differential equations.
No, actually. It's a strongly (validated) model-based creature, which has its own shortcomings, but it's not really a statistical creature.
A cow is actually a rather topologically interesting beast.
Nah, it's just a funny torus.
Actually, one of the most dangerous uses of statistics is exactly predicting with them inappropriately. Curve fitting is especially prone to this error- attempting to make any predictions outside of the central mass of the points used to *produce* the curve is completely bogus, and yet people do it all the time.
I think this is largely a function of how OOP is taught- including the languages used to teach it. Too many people start with Java and its "everything is an object! but they're not all first-class objects! and we're going to try to hide it all from you even though you have to know the details anyway!" design principles instead of a language that either a) cleanly mixes OOP in with procedures *not* tied to objects, or b) is a fully OOP-supportive language in which everything really is a first-class object.
Instead we get "Java is OOP, C is not" when in truth you can easily do non-OOP programming in Java and OOP programming in pure C (and, as you pointed out, a lot of C from quite a ways back shows a lot of the features of OOP programming).
From my perspective, this is actually the correct prioritization- did anyone not know by now that Windows 7 has been very well received and is selling well? And, given that, it overtaking OS X in market share is more than a little obvious- if it *hadn't*, it'd be newsworthy.
Tab handling can be a fairly acrimonious debate among developers, though, so a change to one of the major tools out there for writing code that impacts that debate is, in fact, quite interesting.
Atoms are large enough that something like this can work despite the required uncertainties in both position and velocity.
That's *generally* true. It's not *always* true.
There are a lot of purely compute-bound applications (think simulations of various sorts, etc) for which the algorithmic optimizations have already been done- but it's still worth going for the last few percent of performance from "instruction fiddling". As another poster said: if your app runs for weeks at a time, 1% improvement becomes significant in terms of time saved- and throwing more hardware at the problem isn't always feasible.