Nokia messed up by not staying the course. And now they announced they are happy being the challenger. Seriously?
It's understandable that one does not have time to keep up with the news, but at least RTF summary TITLE. Digia releases Qt 5.1. Nokia has had nothing to do with Qt for the last year or so, which is a Good Thing for the toolkit's evolution.
Since you want to touch on this... heck, I have karma to burn, so why not?
Third, please find me a free market today that works the way the model predicts, and isn't literally destroying people in the process, merely to maximize profits.
As you well pointed out, this is not a realistic option. And the cause is simple, profit maximization misalignment with other motivations - in fact, it's inherent in free markets, where competing interests (for profit) motivate everything. Hence various side effects like negative externalities, worker exploitation, slavery, and so on.
My personal take on this is that while a real-world free market would be a system with too much complexity and chaotic behaviour to represent in a general model, simplified models with free-market rules can easily show ways in which the system reaches... inefficient outcomes, like unfortunate equilibrium points (such as monopolies) or destructive oscillating behaviour (boom-bust cycles). It does not even require human flaws to get there, game theoretical models with rational agents will reach the same problem, due to inherent limitations such as imperfect information and unstable equilibria. Socialism in turn, besides not really being the alternative, has its own issues, some specific and some not so much (the unstable equilibrium of requiring every participant to have motivations aligned with a common good for one). The tricky part is, imho, the fact that legislating the market is not a true solution - introduce into the game the motivations of legislators and the issue of technical expertise required for tuning the system and you'll just run into a different 'who watches the watchers' class of problems.
To close this rant, IMHO markets need to be seen through dynamic models where there are often (if not always) segments to be watched for developments of bad outcomes - and I'm including regulators in the definition of 'markets'. Having a blind faith in either 'free' or 'regulated' is a lazy man's easy way out of an argument that is too complex to tackle, as market efficiency is something that requires vigilance from all participants, much like liberty.
The link you gave provided little insight into its cause. Do you have any more information about it?
The way I see it it's about the structure of the trades. From their text above the plots:
The price dropped from $796 to $775 in about 3/4 of a second, then rebounded to $793 a second later. The drop invovled 307 trades and 57,255 shares from 10 exchanges + dark pools. During the drop, there were 5 orders placed for every trade executed (meaning 4 orders placed/canceled for every trade).
Having about 1.5k quotes posted in 0.75s (with 80% being canceled) surely shows that HFT algos were active and yet did not absorb 57k shares of GOOG (that's about 2.5% of the daily volume at the time). Which is not a thinly traded stock by any measure. It's not a conclusive proof of HFT causing a drop of 2.5% in less than a second though, but I don't think you can easily get such a proof without knowing who traded what. There is only so much one can glean from trade data at this level after all.
Due to some time constraints I'll beg to be excused if, in lieu of the rest of the comment I was going to post, I'll give you this example (originally from here but the harvard link seems unavailable) of a HFT technique that, shall we say, 'plays' liquidity to increase volatility. The problem, as I see it, is how to discourage people who have the means to use them in such a fashion. Bear in mind that HFT requires quite an investment in infrastructure and software, so voluntarily refraining from taking advantage of that infrastructure in ways that exploit its advantage at the expense of slower traders is not a believable option. However, I'll also freely state that I have little faith in simple-sounding solutions to complex problems, which is what most pro- and anti-HFT rhetoric brings. Fortunately, it is not my job to find the proper solutions:-)
Some kinds of trading, including high-frequency trading, add liquidity; participants that do this are called market makers, and market makers reduce volatility by making it cost more to move the price.
Apologies, but you are mistaken. Market makers, in order to qualify as such (and receive the official designation from an exchange) have to satisfy certain condition that are not satisfied by HFT operations. The relevant ones for the 'provide liquidity' part are: to always maintain bid/ask quotes and stand by to execute trades at the quoted prices. There are rare exceptions when one can pull off, but that's the gist of it. Bit of a quaint notion nowadays, what with multiple connected electronic venues, but some exchanges still have it and it does use electronic quoting nowadays. However, this little detail does disqualify the majority if not all HFT shops from market making in the conventional sense.
Now, the good part that fast electronic trading does (which is not exactly the same as HFT) is pricing arbitrage between exchanges. Securities listed on multiple exchanges and/or in dark pools often enough get crossing prices, where one can arbitrate the difference and re-bring quotes in line. For example, when a price starts moving on one exchange (due to a block trade, let's say) price propagation is something that nowadays happens a lot faster. Similar things can be done with arbitrages between underlying instrument prices and derivative ones. If you choose to include this in HFT, then I'll grant you it's a good thing and it does improve liquidity[*]. It still does not make HFT players market makers, but arbitrageurs are good for price discovery[**]. However, you can't quite separate this part from the *ahem* 'evil' one, as you called it. It's simple market opportunity taking. Well, at least you cannot unless you start requiring a set of conditions that would make it unprofitable to engage in the behaviour you want to prevent.
Finally, going back to my original post, please do follow the link in there. It's not about 'the' flash crash, but one of the many single-stock flash crashes that happened since. This one was on GOOG, which is not an illiquid stock, and lasted less than 2 seconds. That's quite different from fat-finger crashes where extra-large orders are mistakenly placed and clear all the bids in the books on their way to the great below. (and btw, I do wish that my posts on this topic would stop getting irrelevant replies about the SPY flash crash when I'm not referring to that one and not even the same type of phenomenon)
[*] by decreasing quote spreads, which is the main proxy used for liquidity measuring. Still, I am yet to see convincing evidence for the part HFT played in this as opposed to the general improvement in connectivity between markets.
[**] However, having an option quote react faster to the price change of the underlying does not necessarily mean I'll get more liquidity for it. The liquidity question is thus tricker than it seems.
So, a thief who steals as much as an HFT corporation is also fine? Without the metric of social value, there is little or no point to many of the laws we have, especially the ones we think of as 'good'. I'd posit that if the social value of HFT is on par with grand theft, it should be outlawed, and for the same reason.
Well, my point is that markets (and in particular capital markets) are fundamentally about profit and nothing else. If you want to impose some additional system of values, be it social, ethical, religious (yes, there is such a thing in capital markets) ones, it has to be done from outside the 'free market' mentality. Because of that it amounts to extra regulation, so whether it is good or bad becomes a hot button issue in the US in general and on/. in particular and I chose to refrain from expressing a preference in a post that was more about facts.
There is no evidence that HFT causes spikes and crashes. Actual evidence says the opposite: by increasing liquidity, HFT reduces volatility.
Actual evidence from the guys who monitor these kind of things says nothing of the sort. I wish people would stop spouting this line about HFT and liquidity. Here is a relatively recent GOOG flash crash (April 22 2013) likely due to HFT (based on timespan and number of trades, number of orders placed per trade and number of exchanges involved).
HFT is a symptom of a deeply broken system. It brings liquidity, which is good, but it has tended to move the market in unreasonable (and sometimes dangerous) ways.
That is a bit simplistic as well. First, stepping in front of a trade because you can (1) see it before the other guy (due to having lower latencies in talking to the exchange or having priority 'fast' data feeds) and (2) quote using fraction of a penny increments as opposed to pennies for the 'regular' guys is not adding liquidity. In fact, from the way flash crashes happen you can see exactly how HFT does not add liquidity with a stock/future going bidless and crashing. Properly supplying liquidity would not allow for something like that to happen.
When talking about long-term stewardship of institutions, we really need to move away from unreasonable earnings expectations every quarter.
Who is we? The short-termism here is the market speaking. The idea of markets setting the 'right' price is highly dependent on your definition of 'right'. As the saying goes, markets can remain irrational longer than one can remain solvent (and bet on rationality). Nevermind the fact that people in the market have different types of interests which are not always aligned to long-term value. See corporate raiders, LBO, and so on - case in point, Icahn.
When the focus of the market is on ever narrowing periods of time, corporations simply cannot properly invest in the future.
That's not entirely the problem. When the upper echelons of the corporations receive stock options with short vesting periods (no, 5 years is not long term compared to typical investment horizons, and 5 years are not really that frequent) the motivation to invest in the long-term future is basically absent. Also, there are industries where that is simply not possible, as the prevailing conditions fluctuate too much.
Ultimately, stock/commodity/bond markets are about profit. There is nothing inherently wrong with that. The question for the rest of us is: what is the social value?
Indeed, profit is the key word. Social value is incidental, if at all.
The thing is, you have it a bit backwards. With a refrigeration cycle, which is basically an engine cycle running backwards, you are moving heat from the lower temperature to the higher one. This requires you to supply work to the cycle - you're converting that work to heat, in fact, not the other way around as you seem to argue (and as an engine would do). It doesn't really matter what work source you use as long as it does what you need - in particular, you can use a separate heat engine system to generate it, going [kerosene wick] heat -> work, which is added to heat from inside the fridge -> heat outside the fridge, but modern appliances use electric pumps, as they scale better, are more efficient (your kerosene engine is quite wasteful) and power is more readily available.
You were talking about installing a driver and my point is that the driver install API won't suddenly stop requiring signed code because the request came from ring 0.
He is right and you have it wrong, I'm afraid. Specifically, if you're running malicious code at ring 0 and you're trying to use the system API to install a driver you're doing it wrong. At that privilege level you can be the API, as you have direct access to kernel memory and the needed structures it contains - as they say, the world is your oyster at that point (at least as far as the local machine is concerned). This is exactly what rootkits do to hide themselves. A more interesting problem is how to ensure persistence across reboots without leaving a traceable fingerprint for rootkit hunters to find.
I will grant them that all the data collected on 200 rats over several years is in sufficient quantity as to not fit into one journal article. That should not mean they did not use all the data for their analysis; however, I'd expect them to have the data available if requested for comparison purposes, otherwise this would start to look pretty fishy.
... and of course this uses his assumption for the chance of false positives, which is basically... wrong. Quite embarrassing for a math student, since instead of stating it as an independent variable (as he should have) he assumes that
where in fact the right hand side is P(test negative | infected), quite a different thing from the left hand side.
If otoh your zombie test has 0 false positives, that.9% will be irrelevant as anyone flagged positive by the test is in fact infected so you'll not be administering the cure to healthy people.
Even poorer judgment, in fact, as his probability calculation relies on an actual rate of infection of 1 in 500. For such a highly contagious disease the rate of infection will grow (well, duh!) So if 1 in 500 gives about 83% false positives, when the infection rate reaches 1 in 50 the false positive chance drops to 33% and for 1 in 5 to 4%.
So indeed 99% is quite good for a high contagion rate, not so good for low contagion and useless for something that's exceedingly rare (for a disease that affects only one person in 10000 a test that has a 99% detection rate will have 99% false positives)
P(no zombies in 100 years) = p(no zombies in year 1)*... * p(no zombies in year 100) = p(no zombies per year)^100 = 0.99^100 = 0.36603... or about 36.6%
similar for the second case, 0.999^1000 = 0.36769... or about 36.8%
I suppose the better illustration of probabilities would be: 99% for a zombie-free year = 36.6% for a zombie-free century 99.9% for a zombie-free year = 90.5% for a zombie-free century 99.99% for a zombie-free year = 99% for a zombie-free century
But Microsoft stock? Very nice dividend. If you don't think a rapidly growing economy is right around the corner you can do far worse than a 3.4% dividend while we wait.
Well, it's a good thing you're not a money manager. MSFT is a company whose stock has gone sideways for the last 10 years (ignoring the dotcom bubble, as that would make it going down and sideways, but not for intrinsic reasons). 3.4% dividend on a stock that goes sideways for 10 years is a joke, even for today's artificially low rates you can get higher yield with high investment grade bonds (say, GE 10y AA, with a 5.5% coupon) for a FAR lower level of risk. OF course, you can do far worse than that, but at this stage a passive buy-and-hold of an index ETF, say SPY, you would have done far better than holding MSFT. Too bad the shareholders don't seem to want a change of leadership at Microsoft, the current Ballmer edition has a too long and too proven track for lack of vision.
You want a system to localise the error? Look up design by contract, and pre and post conditions. It's all there.
And you bring this up to justify assert()ing... fun stuff. Aside from the fact that it's completely irrelevant to the example i gave - which was intentionally far-corner case in that it had a high enough probability of hardware errors, where neither asserts nor design by contract solve anything (the correct answer would have been fault-tolerant computing at hardware level). I'll concede that mine was a poor example, but it did have the redeeming quality of generating an amusing reply.
I made a point about asserts having a place in release builds. You tried arguing something else that I didn't say, and in the process you actually accepted my point.
Sorry, no. Go back and re-read. I said aborting has places in release builds. Using assert for that is just a lazy man's solution. You're just doing if(...) then abort(), with some extra printout of where it aborted with no useful context as to why and how it got there. That's not going to help a developer understand what happened, especially since it's likely a context that occurred in production but not in testing. Ignoring the fact that one release manager later the compile flags might have an extra -DNDEBUG and your 'checks' vanished. Feel free to stick to it, but it still makes for bad programming practice. I would advise writing a different piece of checking code that provides more information and has more flexibility in dealing with the error than shutting everything up.
I've not been programming for just 10 years, I've been programming since 1979.
Good for you. I however only want to avoid installing software that i would need now and was produced following dubious coding standards, so that means reasonably recent and 10 years should cover it. Sadly, it's an impossible task in absolute terms, but every little bit helps.
Sure Sparky, you can certainly have unforseen errors. You send a rover to Mars, and the whole computing system is bombarded with high energy radiation in much larger doses than here. Chances of having a bit flipped in a constant go up a bit (depending on your hardware mitigation measures). The problem is, when does it happen? Was your assert too late and damage is already done? Does it happen immediately after your assert? Heck you're only testing one place in a cached hierarchy, what if it's already inconsistent in other places?
There are ways to mitigate depending on how important your whole setup is. Of course aborting is an acceptable way, but only when things are so bad that context no longer matters. There are severity levels on errors and the vast majority should not abort. This case is especially egregious as it is a shared library doing input validation and asserting on unexpected input (ignoring for a moment that the input is valid per standard). This is the last thing you want to do in this case - scratch that, it's not even the last thing. The apache example I gave above, doing THE SAME MISTAKE but web facing, is a DOS waiting to happen. If you think that is fine, please let me know where you have worked in the last 10 years so I can blacklist those vendors.
Programmer stupidity (or rather inattentiveness) is not limited to debug code, so why limit asserts to it?
Because on failure assert() calls abort(), which is a good behavior if you're debugging code but is unacceptable for code shipped out to customers.[*] And the reason is, if you know you might have unexpected input there are other tools to approach it in release mode: if, switch, exceptions, your own custom macros and so on. Assert is for code that has to evaluate to true, otherwise it's a programming error (for a beginner example, bounds checking for array access). If you're using it for release code it's a programmer error, and if it triggers in release code it means you have an inattentive programmer, a testing problem and a design error. And if it happens in a system library that's used by most programs in your OS...
[*] Image for a moment that you had patched up apache to assert() whether an URL/URI is valid or not, same as here but web-facing Your webserver's uptime would be measured in seconds.
For a thermodynamic system, zero temperature is when you can't vary (as in... decrease it) the internal energy of the system, the order of system is maximum.
For a "negative temperature system" (no longer a thermodynamic one), this translates into "after a point, one can no longer pump energy into the system, the order has reach the maximum".
This is... inexact.
A zero temperature system is one where energy fluctuations are zero. Or, if you want the third principle definition, is a system with zero entropy. This will immediately tell you why you cannot reach absolute zero - you have to lose not only thermodynamic fluctuations, but quantum ones as well, which is impossible.
A negative temperature system, otoh, is one where you have a population inversion on the energy level distribution. The elementary case is a 2-level system where the higher energy level has a higher occupation than the lower one. In order to follow the appropriate statistical distribution (M-B, B-E or F-D, depending on the system) the temperature has to be negative. The transition happens through the point of equal occupation, which corresponds to 1/T = 0, so T "wraps around" through infinite temperature (a theoretical construct, as you pointed out further down in the thread).
What you are describing is a system who has *all* its components in the higher state (so that no more energy can be pumped, as there's nothing left to absorb it). This is indeed a case of negative temperature, but a trivial writing down of its distribution will let you know that you are at T = -0 (or 1/T = - infinity), which is as impossible to achieve in practice as the T = +0 case.
Lactose intolerant people can digest cheese just fine (for the most part). Milk lactose is largely drained with the liquid in the process of curdling, so cheese has little lactose left. That's likely why people used cheese before having developed lactose tolerance - because they discovered it was safe to digest.
If someone has hacked into the site to obtain the hashes, it's likely they can do other stuff anyway (make transactions, get your info, maybe even get the plaintext of your password), so don't waste your time making and using super long passwords.
This is not always true tbh. Stealing hashes can require as little as an unsanitized SQL query in a web application that allows an attacker to dump the hash table(s) using nothing more than a browser. It may or may not allow for user impersonation in order to do the stuff you listed, but the point is stealing hashes does not have to require complete hacking. In such a scenario strong passwords are still quite useful.
Automated control system and/or safety checks failure, most likely - at that speed manual braking is useless (by the time you have visual on the obstacle it's too late to brake). The automated control system should have detected that one train was no longer moving or no longer in contact and should have slowed down/halted all other trains on the same track approaching the area.
Seeing that the alternatives at the moment are not exactly in the same league, they could do with more users/testing. And waiting for the Linux Skype client to be almost unable to talk to the Skype servers due to being extremely out-of-date (aside: anyone using the official Yahoo Messenger Linux client these days?) is not a good way to help having an alternative to jump to by that time.
I'm a medicinal chemist working on a program to cure Alzheimer's disease, and I thank God for my abilities. I think you presume too much of the Doctor when you deny the existence of miracles.
You might want to reconsider your understanding of critical thinking (and, by extension, scientific research) if you derive the existence of a God from the existence of what you call miracles.
you're missing at least Huawei on the asian side. Also, I wouldn't call Ericsson (the current market leader) a division of Sony Ericsson, it's actually the other way around, the latter is a joint venture between Sony and Ericsson.
Slashdot Mirror
Nokia messed up by not staying the course. And now they announced they are happy being the challenger. Seriously?
It's understandable that one does not have time to keep up with the news, but at least RTF summary TITLE. Digia releases Qt 5.1. Nokia has had nothing to do with Qt for the last year or so, which is a Good Thing for the toolkit's evolution.
Since you want to touch on this ... heck, I have karma to burn, so why not?
Third, please find me a free market today that works the way the model predicts, and isn't literally destroying people in the process, merely to maximize profits.
As you well pointed out, this is not a realistic option. And the cause is simple, profit maximization misalignment with other motivations - in fact, it's inherent in free markets, where competing interests (for profit) motivate everything. Hence various side effects like negative externalities, worker exploitation, slavery, and so on.
My personal take on this is that while a real-world free market would be a system with too much complexity and chaotic behaviour to represent in a general model, simplified models with free-market rules can easily show ways in which the system reaches ... inefficient outcomes, like unfortunate equilibrium points (such as monopolies) or destructive oscillating behaviour (boom-bust cycles). It does not even require human flaws to get there, game theoretical models with rational agents will reach the same problem, due to inherent limitations such as imperfect information and unstable equilibria. Socialism in turn, besides not really being the alternative, has its own issues, some specific and some not so much (the unstable equilibrium of requiring every participant to have motivations aligned with a common good for one). The tricky part is, imho, the fact that legislating the market is not a true solution - introduce into the game the motivations of legislators and the issue of technical expertise required for tuning the system and you'll just run into a different 'who watches the watchers' class of problems.
To close this rant, IMHO markets need to be seen through dynamic models where there are often (if not always) segments to be watched for developments of bad outcomes - and I'm including regulators in the definition of 'markets'. Having a blind faith in either 'free' or 'regulated' is a lazy man's easy way out of an argument that is too complex to tackle, as market efficiency is something that requires vigilance from all participants, much like liberty.
The link you gave provided little insight into its cause. Do you have any more information about it?
The way I see it it's about the structure of the trades. From their text above the plots:
The price dropped from $796 to $775 in about 3/4 of a second, then rebounded to $793 a second later. The drop invovled 307 trades and 57,255 shares from 10 exchanges + dark pools. During the drop, there were 5 orders placed for every trade executed (meaning 4 orders placed/canceled for every trade).
Having about 1.5k quotes posted in 0.75s (with 80% being canceled) surely shows that HFT algos were active and yet did not absorb 57k shares of GOOG (that's about 2.5% of the daily volume at the time). Which is not a thinly traded stock by any measure. It's not a conclusive proof of HFT causing a drop of 2.5% in less than a second though, but I don't think you can easily get such a proof without knowing who traded what. There is only so much one can glean from trade data at this level after all.
Due to some time constraints I'll beg to be excused if, in lieu of the rest of the comment I was going to post, I'll give you this example (originally from here but the harvard link seems unavailable) of a HFT technique that, shall we say, 'plays' liquidity to increase volatility. The problem, as I see it, is how to discourage people who have the means to use them in such a fashion. Bear in mind that HFT requires quite an investment in infrastructure and software, so voluntarily refraining from taking advantage of that infrastructure in ways that exploit its advantage at the expense of slower traders is not a believable option. However, I'll also freely state that I have little faith in simple-sounding solutions to complex problems, which is what most pro- and anti-HFT rhetoric brings. Fortunately, it is not my job to find the proper solutions :-)
Some kinds of trading, including high-frequency trading, add liquidity; participants that do this are called market makers, and market makers reduce volatility by making it cost more to move the price.
Apologies, but you are mistaken. Market makers, in order to qualify as such (and receive the official designation from an exchange) have to satisfy certain condition that are not satisfied by HFT operations. The relevant ones for the 'provide liquidity' part are: to always maintain bid/ask quotes and stand by to execute trades at the quoted prices. There are rare exceptions when one can pull off, but that's the gist of it. Bit of a quaint notion nowadays, what with multiple connected electronic venues, but some exchanges still have it and it does use electronic quoting nowadays. However, this little detail does disqualify the majority if not all HFT shops from market making in the conventional sense.
Now, the good part that fast electronic trading does (which is not exactly the same as HFT) is pricing arbitrage between exchanges. Securities listed on multiple exchanges and/or in dark pools often enough get crossing prices, where one can arbitrate the difference and re-bring quotes in line. For example, when a price starts moving on one exchange (due to a block trade, let's say) price propagation is something that nowadays happens a lot faster. Similar things can be done with arbitrages between underlying instrument prices and derivative ones. If you choose to include this in HFT, then I'll grant you it's a good thing and it does improve liquidity[*]. It still does not make HFT players market makers, but arbitrageurs are good for price discovery[**]. However, you can't quite separate this part from the *ahem* 'evil' one, as you called it. It's simple market opportunity taking. Well, at least you cannot unless you start requiring a set of conditions that would make it unprofitable to engage in the behaviour you want to prevent.
Finally, going back to my original post, please do follow the link in there. It's not about 'the' flash crash, but one of the many single-stock flash crashes that happened since. This one was on GOOG, which is not an illiquid stock, and lasted less than 2 seconds. That's quite different from fat-finger crashes where extra-large orders are mistakenly placed and clear all the bids in the books on their way to the great below. (and btw, I do wish that my posts on this topic would stop getting irrelevant replies about the SPY flash crash when I'm not referring to that one and not even the same type of phenomenon)
[*] by decreasing quote spreads, which is the main proxy used for liquidity measuring. Still, I am yet to see convincing evidence for the part HFT played in this as opposed to the general improvement in connectivity between markets.
[**] However, having an option quote react faster to the price change of the underlying does not necessarily mean I'll get more liquidity for it. The liquidity question is thus tricker than it seems.
So, a thief who steals as much as an HFT corporation is also fine? Without the metric of social value, there is little or no point to many of the laws we have, especially the ones we think of as 'good'. I'd posit that if the social value of HFT is on par with grand theft, it should be outlawed, and for the same reason.
Well, my point is that markets (and in particular capital markets) are fundamentally about profit and nothing else. If you want to impose some additional system of values, be it social, ethical, religious (yes, there is such a thing in capital markets) ones, it has to be done from outside the 'free market' mentality. Because of that it amounts to extra regulation, so whether it is good or bad becomes a hot button issue in the US in general and on /. in particular and I chose to refrain from expressing a preference in a post that was more about facts.
There is no evidence that HFT causes spikes and crashes. Actual evidence says the opposite: by increasing liquidity, HFT reduces volatility.
Actual evidence from the guys who monitor these kind of things says nothing of the sort. I wish people would stop spouting this line about HFT and liquidity. Here is a relatively recent GOOG flash crash (April 22 2013) likely due to HFT (based on timespan and number of trades, number of orders placed per trade and number of exchanges involved).
HFT is a symptom of a deeply broken system. It brings liquidity, which is good, but it has tended to move the market in unreasonable (and sometimes dangerous) ways.
That is a bit simplistic as well. First, stepping in front of a trade because you can (1) see it before the other guy (due to having lower latencies in talking to the exchange or having priority 'fast' data feeds) and (2) quote using fraction of a penny increments as opposed to pennies for the 'regular' guys is not adding liquidity. In fact, from the way flash crashes happen you can see exactly how HFT does not add liquidity with a stock/future going bidless and crashing. Properly supplying liquidity would not allow for something like that to happen.
When talking about long-term stewardship of institutions, we really need to move away from unreasonable earnings expectations every quarter.
Who is we? The short-termism here is the market speaking. The idea of markets setting the 'right' price is highly dependent on your definition of 'right'. As the saying goes, markets can remain irrational longer than one can remain solvent (and bet on rationality). Nevermind the fact that people in the market have different types of interests which are not always aligned to long-term value. See corporate raiders, LBO, and so on - case in point, Icahn.
When the focus of the market is on ever narrowing periods of time, corporations simply cannot properly invest in the future.
That's not entirely the problem. When the upper echelons of the corporations receive stock options with short vesting periods (no, 5 years is not long term compared to typical investment horizons, and 5 years are not really that frequent) the motivation to invest in the long-term future is basically absent. Also, there are industries where that is simply not possible, as the prevailing conditions fluctuate too much.
Ultimately, stock/commodity/bond markets are about profit. There is nothing inherently wrong with that. The question for the rest of us is: what is the social value?
Indeed, profit is the key word. Social value is incidental, if at all.
The thing is, you have it a bit backwards. With a refrigeration cycle, which is basically an engine cycle running backwards, you are moving heat from the lower temperature to the higher one. This requires you to supply work to the cycle - you're converting that work to heat, in fact, not the other way around as you seem to argue (and as an engine would do). It doesn't really matter what work source you use as long as it does what you need - in particular, you can use a separate heat engine system to generate it, going [kerosene wick] heat -> work, which is added to heat from inside the fridge -> heat outside the fridge, but modern appliances use electric pumps, as they scale better, are more efficient (your kerosene engine is quite wasteful) and power is more readily available.
You were talking about installing a driver and my point is that the driver install API won't suddenly stop requiring signed code because the request came from ring 0.
He is right and you have it wrong, I'm afraid. Specifically, if you're running malicious code at ring 0 and you're trying to use the system API to install a driver you're doing it wrong. At that privilege level you can be the API, as you have direct access to kernel memory and the needed structures it contains - as they say, the world is your oyster at that point (at least as far as the local machine is concerned). This is exactly what rootkits do to hide themselves. A more interesting problem is how to ensure persistence across reboots without leaving a traceable fingerprint for rootkit hunters to find.
They seemed to have answered the rat strain criticism and the food intake one here, among other things:
http://www.sciencedirect.com/science/article/pii/S0278691512008149
I will grant them that all the data collected on 200 rats over several years is in sufficient quantity as to not fit into one journal article. That should not mean they did not use all the data for their analysis; however, I'd expect them to have the data available if requested for comparison purposes, otherwise this would start to look pretty fishy.
let's see ... google gmo liver damage ... first link is
http://worldcrunch.com/tech-science/new-study-says-monsanto-gm-corn-causes-tumors-kidney-and-liver-disease/gmo-nk602-monsanto-tumors-corn/c4s9636/
(paper link at http://www.sciencedirect.com/science/article/pii/S0278691512005637)
Feel free to abuse google further on the subject. And ofc pertinent criticism is welcome.
... and of course this uses his assumption for the chance of false positives, which is basically ... wrong. Quite embarrassing for a math student, since instead of stating it as an independent variable (as he should have) he assumes that
P(test positive | not infected) = 1 - P(test positive | infected)
where in fact the right hand side is P(test negative | infected), quite a different thing from the left hand side.
If otoh your zombie test has 0 false positives, that .9% will be irrelevant as anyone flagged positive by the test is in fact infected so you'll not be administering the cure to healthy people.
Even poorer judgment, in fact, as his probability calculation relies on an actual rate of infection of 1 in 500. For such a highly contagious disease the rate of infection will grow (well, duh!) So if 1 in 500 gives about 83% false positives, when the infection rate reaches 1 in 50 the false positive chance drops to 33% and for 1 in 5 to 4%.
So indeed 99% is quite good for a high contagion rate, not so good for low contagion and useless for something that's exceedingly rare (for a disease that affects only one person in 10000 a test that has a 99% detection rate will have 99% false positives)
How does 99% over 100 years work out to only 63%?
P(no zombies in 100 years) = p(no zombies in year 1)* ... * p(no zombies in year 100)
= p(no zombies per year)^100 = 0.99^100 = 0.36603... or about 36.6%
similar for the second case, 0.999^1000 = 0.36769... or about 36.8%
I suppose the better illustration of probabilities would be:
99% for a zombie-free year = 36.6% for a zombie-free century
99.9% for a zombie-free year = 90.5% for a zombie-free century
99.99% for a zombie-free year = 99% for a zombie-free century
But Microsoft stock? Very nice dividend. If you don't think a rapidly growing economy is right around the corner you can do far worse than a 3.4% dividend while we wait.
Well, it's a good thing you're not a money manager. MSFT is a company whose stock has gone sideways for the last 10 years (ignoring the dotcom bubble, as that would make it going down and sideways, but not for intrinsic reasons). 3.4% dividend on a stock that goes sideways for 10 years is a joke, even for today's artificially low rates you can get higher yield with high investment grade bonds (say, GE 10y AA, with a 5.5% coupon) for a FAR lower level of risk. OF course, you can do far worse than that, but at this stage a passive buy-and-hold of an index ETF, say SPY, you would have done far better than holding MSFT. Too bad the shareholders don't seem to want a change of leadership at Microsoft, the current Ballmer edition has a too long and too proven track for lack of vision.
You want a system to localise the error? Look up design by contract, and pre and post conditions. It's all there.
And you bring this up to justify assert()ing ... fun stuff. Aside from the fact that it's completely irrelevant to the example i gave - which was intentionally far-corner case in that it had a high enough probability of hardware errors, where neither asserts nor design by contract solve anything (the correct answer would have been fault-tolerant computing at hardware level). I'll concede that mine was a poor example, but it did have the redeeming quality of generating an amusing reply.
I made a point about asserts having a place in release builds. You tried arguing something else that I didn't say, and in the process you actually accepted my point.
Sorry, no. Go back and re-read. I said aborting has places in release builds. Using assert for that is just a lazy man's solution. You're just doing if(...) then abort(), with some extra printout of where it aborted with no useful context as to why and how it got there. That's not going to help a developer understand what happened, especially since it's likely a context that occurred in production but not in testing. Ignoring the fact that one release manager later the compile flags might have an extra -DNDEBUG and your 'checks' vanished. Feel free to stick to it, but it still makes for bad programming practice. I would advise writing a different piece of checking code that provides more information and has more flexibility in dealing with the error than shutting everything up.
I've not been programming for just 10 years, I've been programming since 1979.
Good for you. I however only want to avoid installing software that i would need now and was produced following dubious coding standards, so that means reasonably recent and 10 years should cover it. Sadly, it's an impossible task in absolute terms, but every little bit helps.
Sure Sparky, you can certainly have unforseen errors. You send a rover to Mars, and the whole computing system is bombarded with high energy radiation in much larger doses than here. Chances of having a bit flipped in a constant go up a bit (depending on your hardware mitigation measures). The problem is, when does it happen? Was your assert too late and damage is already done? Does it happen immediately after your assert? Heck you're only testing one place in a cached hierarchy, what if it's already inconsistent in other places?
There are ways to mitigate depending on how important your whole setup is. Of course aborting is an acceptable way, but only when things are so bad that context no longer matters. There are severity levels on errors and the vast majority should not abort. This case is especially egregious as it is a shared library doing input validation and asserting on unexpected input (ignoring for a moment that the input is valid per standard). This is the last thing you want to do in this case - scratch that, it's not even the last thing. The apache example I gave above, doing THE SAME MISTAKE but web facing, is a DOS waiting to happen. If you think that is fine, please let me know where you have worked in the last 10 years so I can blacklist those vendors.
Programmer stupidity (or rather inattentiveness) is not limited to debug code, so why limit asserts to it?
Because on failure assert() calls abort(), which is a good behavior if you're debugging code but is unacceptable for code shipped out to customers.[*] And the reason is, if you know you might have unexpected input there are other tools to approach it in release mode: if, switch, exceptions, your own custom macros and so on. Assert is for code that has to evaluate to true, otherwise it's a programming error (for a beginner example, bounds checking for array access). If you're using it for release code it's a programmer error, and if it triggers in release code it means you have an inattentive programmer, a testing problem and a design error. And if it happens in a system library that's used by most programs in your OS ...
[*] Image for a moment that you had patched up apache to assert() whether an URL/URI is valid or not, same as here but web-facing Your webserver's uptime would be measured in seconds.
For a thermodynamic system, zero temperature is when you can't vary (as in... decrease it) the internal energy of the system, the order of system is maximum.
For a "negative temperature system" (no longer a thermodynamic one), this translates into "after a point, one can no longer pump energy into the system, the order has reach the maximum".
This is ... inexact.
A zero temperature system is one where energy fluctuations are zero. Or, if you want the third principle definition, is a system with zero entropy. This will immediately tell you why you cannot reach absolute zero - you have to lose not only thermodynamic fluctuations, but quantum ones as well, which is impossible.
A negative temperature system, otoh, is one where you have a population inversion on the energy level distribution. The elementary case is a 2-level system where the higher energy level has a higher occupation than the lower one. In order to follow the appropriate statistical distribution (M-B, B-E or F-D, depending on the system) the temperature has to be negative. The transition happens through the point of equal occupation, which corresponds to 1/T = 0, so T "wraps around" through infinite temperature (a theoretical construct, as you pointed out further down in the thread).
What you are describing is a system who has *all* its components in the higher state (so that no more energy can be pumped, as there's nothing left to absorb it). This is indeed a case of negative temperature, but a trivial writing down of its distribution will let you know that you are at T = -0 (or 1/T = - infinity), which is as impossible to achieve in practice as the T = +0 case.
Lactose intolerant people can digest cheese just fine (for the most part). Milk lactose is largely drained with the liquid in the process of curdling, so cheese has little lactose left. That's likely why people used cheese before having developed lactose tolerance - because they discovered it was safe to digest.
If someone has hacked into the site to obtain the hashes, it's likely they can do other stuff anyway (make transactions, get your info, maybe even get the plaintext of your password), so don't waste your time making and using super long passwords.
This is not always true tbh. Stealing hashes can require as little as an unsanitized SQL query in a web application that allows an attacker to dump the hash table(s) using nothing more than a browser. It may or may not allow for user impersonation in order to do the stuff you listed, but the point is stealing hashes does not have to require complete hacking. In such a scenario strong passwords are still quite useful.
Automated control system and/or safety checks failure, most likely - at that speed manual braking is useless (by the time you have visual on the obstacle it's too late to brake). The automated control system should have detected that one train was no longer moving or no longer in contact and should have slowed down/halted all other trains on the same track approaching the area.
Seeing that the alternatives at the moment are not exactly in the same league, they could do with more users/testing. And waiting for the Linux Skype client to be almost unable to talk to the Skype servers due to being extremely out-of-date (aside: anyone using the official Yahoo Messenger Linux client these days?) is not a good way to help having an alternative to jump to by that time.
I'm a medicinal chemist working on a program to cure Alzheimer's disease, and I thank God for my abilities. I think you presume too much of the Doctor when you deny the existence of miracles.
You might want to reconsider your understanding of critical thinking (and, by extension, scientific research) if you derive the existence of a God from the existence of what you call miracles.
you're missing at least Huawei on the asian side. Also, I wouldn't call Ericsson (the current market leader) a division of Sony Ericsson, it's actually the other way around, the latter is a joint venture between Sony and Ericsson.