I would defy you to pass one of my chemistry classes without attending class.
I have never had a student pass without regular attendance. I've taught at three public universities, two private colleges and physics at one public community college (so I think my student demographic has been quite diverse).
I did not REQUIRE attendance to pass, nor link grades/points to attendance in any, way shape or form. Scores/final grades were 100% performance based.
I only rarely lectured on material not in the text book, though I often presented the material differently than the text presentation.
As I told my students on the first day, "I don't care if you learn it from me, the book, your room mate or who ever, if you can do the work, you'll pass."
Generally, the people who did not attend regularly scored in the teens on the tests, or even single digits, on the tests.
He did not say that this was the third time taking HIS class...he may have just met her.
Or maybe he (or another teacher) HAS suggested she improve her note-taking strategies. Students don't always follow the advice teachers give for succeeding in a given class.
I was teaching chemistry at a small private college a few years ago, and had one girl in class with her laptop open every day. She consistently scored in the 20's on tests.
The rest of the class sat somewhat paying attention (as much as you can in an 8:00 class, I guess), listening, writing down what I indicated was material they may wish to take note of or review later. They did MUUUUCH bettter on the tests.
Sorting out the direction with multiple echoes is not that difficult. The real sound is always first; the path the echo takes is always longer, so the sound is delayed. Thus echoes won't fool an electronic sensor and don't usually fool trained personnel.
The original version of file originated in Unix Research Version 4 in 1973... file's position-sensitive tests are normally implemented by matching various locations within the file against a textual database of magic numbers (see the Usage section). This differs from other simpler methods such as file extensions and schemes like MIME.
Even if you happen to believe that the real improvements to file were not made until System V, that was 1983...so not decadeS, but decade.
So no, not a troll and not revisionist. You make it sound like Unix was not usable until the 1990's.
So the "design specs" you are referring to are non-existent, or simply say "make it compatible with the way the world has been doing things forever".
But the Unix world, which predates both Windows and MS-DOS, has NOT done it this way - EVER. This is the difference between an OS designed for true industrial use and one that is a bolt-on to a single user, mostly trusted environment system. Therefore, it IS a design problem. And it WILL be hard to fix.
This is good advice overall, and I'll continue to take a middle ground approach to it. That is, I'll continue to support MySQL (on whatever distro) for my clients. I don't offer general MySQL support, but when I 'design' a system for my clients, I support whatever OSS stuff goes into that system. If MySQL is the best fit for their needs, that's what I recommend. If it needs support, they call ME.
So, I'm not out there selling MySQL support to anybody that wants it, but I do take care of MY clients. That said, I service ONLY small businesses - nothing remotely like the kind of market the MySQL AB team targets, but I think the OSS + Support ecosystem is big/diverse enough to handle a bunch more niche providers like me.
Then again given the amount of helpful people around not wanting a dime for the help they provide, the only people giving a damn are those people paying for an enterprise version of Linux.
Community support is a great thing, and hopefully all of us that USE F/OSS software give back to that in some way. But the business world, and many individuals, operate on the principle of "you get what you pay for." Most of the time this is a good guideline, but F/OSS is an exception. There are QUALITY products out there, and quality support, available for no upfront financial cost. But in the minds of many business types, if you pay nothing, it must be worth nothing.
(car analogy to follow)
Think about it this way; would you take a FREE car without ANY suspicion that there's something wrong with it? Perhaps, if you knew the seller and trusted him. You and I trust the seller (the OSS community) to provide good products and services, but the average PHB does not know this community - he cannot trust his enterprise with such an unknown.
Another way to put it is that you and I can see the VALUE, independent of price, of OSS, but many others don't. They associate the value with the price tag. Without PAID support, the support is worthless.
Most of the places I've worked have used Red Hat, because it has an enterprise reputation.
Point of clarification: places have RH because they offer support to their enterprise product. Debian's reputation for stability and such is pretty strong, but that only carries so far in the business setting. It's not reputation that drives RH over Deb to the enterprise...it's "I can pay YOU to fix it when it's broke." JMO.
MySQL (the support company) no longer sells support for Debian.
It seems to me that this decision must be driven by sales or market research indicated there is no market for support contracts on Debian based systems. So, does this challenge the notion that OSS can work in a capitalist world when the real "product" is support?
Debian based distros are a significant chunck of the Linux market|mindshare. This decision essentially means the combination of Debian + MySQL is doomed in the business setting.
On the other hand, this does seem to show that there IS a market for support on RH based distros.
In fact, as I think about it, I think what this is really saying is that they want to support MySQL, NOT the underlying OS. Perhaps they have some data that shows that many of their support calls are really for the OS or other parts of the system. In making this decision, they don't rope themselves into having to support anything but MySQL. They can answer a non-relevant (to them) call with "oh, that's an OS issue - call your OS support provider." I'd say that's fair.
It also helps them when there is a problem with MySQL on a client system...THEY can call RH (or whomever) support to make sure everybody gets things 'right.' No, the more I think about it, the more I think this actually strengthens the "give away the software, sell support" model.
Maybe the reason that 99.99% of your problems came from Windows issues is that since you don't use Windows, maybe you just don't know what the hell you're doing when it comes to Windows.
That is almost true. *I* don't know about Windows. That's why my responsibility on the project was only the Linux side of the equation. There was a separate Windows person from the company that supports their Windows computers day-to-day.
Warning: Opinion and Anecdotal discussion to follow; one size does NOT fit all.
All this focus on interoperability is ASSUMING businesses care about operating with Windows. Certainly some do, and they may care about interoperability issues. Others don't; I know my consulting business is a near-nonexistent speck in the grand scheme of things, but I care not one whit about interoperating with Windows. My business is Linux based, and when I set up protocols for dealing with clients, they include cross-platform data formats.
The only time I care about interop with Windows is when a client has a specific need - like the VPN I designed for a client last year. And what I found in that project was 99.99% of ALL the project headaches came from Windows - activation issues, 2003 Server licensing issues, 2003 Server MTU problems, etc.
Anymore, if a client is completely Windows centric and demands a Windows centric solution to their problem, I typically to not even submit a proposal. That's how I view all this interoperability stuff - it is the OTHER players that must conform to the Windows way of doing things; there is no INTERoperability (imho) - it's "operate with Windows' closed way of doing everything, or go play somewhere else."
Well, my business is playing somewhere else. My experience, and those of my clients, is that the solutions I provide LAST and don't force them into Vendor Lock-In and similar, related nonsense. As I said above, this approach is not for everybody.
Hmmm, Not in my training and experience
on
Arson Science Rewritten
·
· Score: 5, Informative
I used to be a volunteer firefighter and also served as a fire investigator. My experience began around 1981 or so; later (late 90s), I worked for a Police Department doing crime scene work and part of that was fire investigation.
From TFA:
Up until the 1990s, this is what fire investigators were taught:
Fires always burn up, not down.
I was NEVER taught that; just the opposite. Fires tend to burn up FASTER than they burn down, but geez, anyone who has ever actually WATCHED a fire burn knows this statement is nonsense.
Fires that burn very fast are fueled by accelerants; "normal" fires burn slowly.
I was NEVER taught that; just the opposite. We were taught that accelerates were ONE WAY a fire MIGHT burn faster than you would expect under similar conditions. We were also taught that is EXTREMELY difficult to gauge how fast a fire "should have" burned. I did my first chemical test on fire debris in 1986 using GC/MS via a very simple headspace analysis on a sample that the state lab sent back as negative (my test was positive for something, perhaps ambient artifacts, but was an educational run, not an 'official' test). With the negative test result, we sure did not try to use evidence of 'how fast that fired burned' to assert the presence of an accelerant.
Arsons fueled by accelerants burn hotter than "normal" fires.
Somebody is oversimplifying the concept of "fire load" here. There are a WHOLE LOT of things than can make a fire burn hotter than 'normal.' In fact, as a common theme I am trying to represent, "normal" is not a well defined term for real-world fires. Rural firefighters and investigators certainly knew this before 1992.
In fact, this statement glosses over another issue about arson - they often, quite often, don't involve 'accelerants' at all.
The clues to arson are clear. Burn holes on the floor indicate multiple points of origin. Finely cracked glass (called "crazed glass") proves a hotter-than-normal fire. So does the collapse of the springs in bedding or furniture, and the appearance of large blisters on charred wood, known as "alligatoring."
The clues to arson are clear?? Man, I clearly remember in the early 1980's being taught exactly the OPPOSITE of what this article says was the "norm" back then. Perhaps it was taught somewhere, but not in RURAL North Carolina. Absolutely NONE of these "clues" are evidence of arson - only of certain fire conditions.
What we were taught in our arson investigation classes, and what I came to learn through experience, is that arson was/is and EXTREMELY difficult crime to prove. That means it is difficult to prove that a fire was arson, much less who did it.
Truthfully, based on my experience, I don't see the point of this article. It asserts 'beliefs' about fire investigation pre-1992 that just are not true.
And finally, the article gives the tragic story of the Lee family that occured in 1989. While presenting NONE of the evidence that was used to convict him, the story creates the straw man that just because it was 1989 and fire investigation changed (around then, according to the article), he must be framed. I don't know of his guilt or innocence, but that's a might big leap of logic.
Whoa, whoa, whoa, whoa, whoa! Let us not get ahead of ourselves here, the right to bear arms in no way gives anyone a right to kill.
Just what do you think the purpose of "arms" is? To dip in chocolate and eat sweets?
What the GP said is very true...as a LAST resort (and he stated it as such), as in when NOTHING else works. In other words, self defense IS generally thought to be justification for killing, at least within the framework of the US legal system. All that is different in this context is that the aggressor is the government itself.
If something doesn't work, it's not that Linux sucks at compatibility with the world, it's that the user sucks for not investing all their time into making it work.
It is not Linux's responsibility to be compatible with the world. The fact of the matter is there is a boatload of usable softare out there, and some for the iPod, btw, that works Just Fine to Get Things Done in Linux. Stop acting like you HAVE to run Windows software on Linux, and then complain if/when it does not work.
If YOU decide to try software written for one OS work on another OS then YOU must invest the time the 'making it work.' Why in the world, again given that Linux-space applications exist for pretty near everything, would that be someone else's responsibility?
It is a bad idea if you are not a member of the elite, and you are trying to resist tyranny and fight for freedom and human rights via non-violent civil disobedience.
You are making the assumption that the crowd in 'crowd control' automatically implies non-violent. Why would anyone want to deploy ANY weapon, lethal or otherwise, on a crowd of non-violent people?(*) Part of the problem is there seems to be a sliding scale of "non-violent civil disobedience" that sometimes includes throwing rocks at innocent passerby, breaking windows, looting, etc.
In other words, it is POSSIBLE to be FOR freedom and human rights and also see that SOMETIMES, those hiding behind the blanket of 'non-violent civil disobedience' are actually rioting.
(*) I know it DOES happen; in those cases, the OP has a good point and in those cases the arguement is bigger than WHICH weapon is used. My objection is to the overgeneralization that ALL protesting crowds are non-violent, which is certainly not the case.
Uh, this "radiation" is just light, and much LOWER energy than the radiation you see with your eyes. The radiation you fear is much HIGHER energy than visible light. Don't be so quick to kneejerk to the word radiation.
How on earth does subtracting the result from a magic value then give you the inverse square root?
Subtracting the right shifted value from the magic value does NOT give the 'inverse square root.' This line of code only gives the initial guess for the Newton-Raphson algorithm.
While the initial guess is a huge part of the real beauty of the algorithm (ie, why it can converge to a sufficiently accurate value after ONLY ONE ITERATION), the 'real work' is done in the
x = x*( 1.5f - xhalf*x*x )
line. That's that application of one iteration of Newton-Raphson (rewritten a bit from what I and others posted earlier, but for this problem algebraically the same). To get more accuracy in the calculation, apply this line repeatedly.
The explanation of the why the magic value - (right shifted int represenation of the float) is a good initial guess is given in the Paper by Chris Lomont linked to in article. Specifically, look on Section 4 beginning on Page 3 of Lomont's article; that's where the fun starts.
In a nutshell, from Lomont, the initial guess is computed "by multiplying the exponent by -1/2, and then picking bits to minimize error." I have not worked through all the details on why this is a good initial guess, but will reemphasize that getting a good result from Newton-Raphson DEPENDS on the initial guess. So, it is not surprising that someone hunted for a general algorithm to find a good initial guess.
Newton-Raphson is a general algorithm for finding root of an equation f(x)=0.
You start with some INITIAL GUESS (the real beauty of this algorithm) X(0), then apply:
X(n+1) = X(n) - f(X(n)) / f'(X(n))
where
X(n+1) is the NEXT guess after the value you 'know',
X(n) is that most recent value you know,
f(X(n)) is the function evaluated at X(n) and
f'(X(n)) is the first derivative of f(x) evaluated at X(n).
It's not foolproof and a BOTH whether it converges at al AND how FAST it converges depends on the initial guess, X(0)
The "Secant Method" is an improvement that makes it a little 'smarter,' at the expense of more computation (this is often a positive trade-off on numerical modeling codes, since the 'smarter' algorithm does tend to converge faster). There are other improvements as well, such as the Los Alamos Linear Feedback Solver (a slightly modified secant method that converges about 10-17% faster, at least for some types of problems) that I use in my own codes.
they've got more business than they can shake a stick at, and it's not going anywhere soon. They have a vested interest in not 'solving' the problem, even if they knew how to do it.
Wow. That simple statement also sums up the War on Drugs.
disclaimer: USED to work in Law Enforcement as part of said "war"...
Yeah. When Apache running on Linux ever breaks through and becomes a highly visible target, LOOK OUT.
Oh wait. That's right. Linux machines ARE visible targets, yet are not pwned in proportion to their use. "Ah," you cry, "but those are servers, not desktops." True. They are servers with purposefully exposed ports and running outside of firewalls; heck, many a Linux Box (PC or embedded) *IS* the firewall for Windows machines. They COULD in principle be compromised and used in botnets like any other computer out there.
The "bigger target, more problems" arguement is flawed. The underlying problem at the system level (ie, not coutnting phishing, physical security problems, etc) is WINDOWS, period. You can argue about whether it is simply the default security model or braindead design all you want, but until that basic reality is accepted, this point of Windows market share is a deflection from the issue.
Are you SERIOUSLY suggesting that short term performance is a better indicated than long term? For long term investments, the 3 month or 1 year is not worth looking at.
Slashdot Mirror
How does "NASA" SAY anything? This is like "The White House Said..."
I would defy you to pass one of my chemistry classes without attending class.
I have never had a student pass without regular attendance. I've taught at three public universities, two private colleges and physics at one public community college (so I think my student demographic has been quite diverse).
I did not REQUIRE attendance to pass, nor link grades/points to attendance in any, way shape or form. Scores/final grades were 100% performance based.
I only rarely lectured on material not in the text book, though I often presented the material differently than the text presentation.
As I told my students on the first day, "I don't care if you learn it from me, the book, your room mate or who ever, if you can do the work, you'll pass."
Generally, the people who did not attend regularly scored in the teens on the tests, or even single digits, on the tests.
He did not say that this was the third time taking HIS class...he may have just met her.
Or maybe he (or another teacher) HAS suggested she improve her note-taking strategies. Students don't always follow the advice teachers give for succeeding in a given class.
I was teaching chemistry at a small private college a few years ago, and had one girl in class with her laptop open every day. She consistently scored in the 20's on tests.
The rest of the class sat somewhat paying attention (as much as you can in an 8:00 class, I guess), listening, writing down what I indicated was material they may wish to take note of or review later. They did MUUUUCH bettter on the tests.
And not all nitrogen containing explosives are white powders. :)
Sorting out the direction with multiple echoes is not that difficult. The real sound is always first; the path the echo takes is always longer, so the sound is delayed. Thus echoes won't fool an electronic sensor and don't usually fool trained personnel.
File was introduced in 1973 and was markedly improved in 1983. That's 10 years or one decade. How does 2006 enter into this discussion?
And UNIX people know this, as it took decades to fix their OS.
... file's position-sensitive tests are normally implemented by matching various locations within the file against a textual database of magic numbers (see the Usage section). This differs from other simpler methods such as file extensions and schemes like MIME.
Speaking specifically about using file extensions, I think 'decades' is a little strong.
From Wikipedia's FILE entry:
The original version of file originated in Unix Research Version 4 in 1973
Even if you happen to believe that the real improvements to file were not made until System V, that was 1983...so not decadeS, but decade.
So no, not a troll and not revisionist. You make it sound like Unix was not usable until the 1990's.
So the "design specs" you are referring to are non-existent, or simply say "make it compatible with the way the world has been doing things forever".
But the Unix world, which predates both Windows and MS-DOS, has NOT done it this way - EVER. This is the difference between an OS designed for true industrial use and one that is a bolt-on to a single user, mostly trusted environment system. Therefore, it IS a design problem. And it WILL be hard to fix.
This is good advice overall, and I'll continue to take a middle ground approach to it. That is, I'll continue to support MySQL (on whatever distro) for my clients. I don't offer general MySQL support, but when I 'design' a system for my clients, I support whatever OSS stuff goes into that system. If MySQL is the best fit for their needs, that's what I recommend. If it needs support, they call ME.
So, I'm not out there selling MySQL support to anybody that wants it, but I do take care of MY clients. That said, I service ONLY small businesses - nothing remotely like the kind of market the MySQL AB team targets, but I think the OSS + Support ecosystem is big/diverse enough to handle a bunch more niche providers like me.
Then again given the amount of helpful people around not wanting a dime for the help they provide, the only people giving a damn are those people paying for an enterprise version of Linux.
Community support is a great thing, and hopefully all of us that USE F/OSS software give back to that in some way. But the business world, and many individuals, operate on the principle of "you get what you pay for." Most of the time this is a good guideline, but F/OSS is an exception. There are QUALITY products out there, and quality support, available for no upfront financial cost. But in the minds of many business types, if you pay nothing, it must be worth nothing.
(car analogy to follow)
Think about it this way; would you take a FREE car without ANY suspicion that there's something wrong with it? Perhaps, if you knew the seller and trusted him. You and I trust the seller (the OSS community) to provide good products and services, but the average PHB does not know this community - he cannot trust his enterprise with such an unknown.
Another way to put it is that you and I can see the VALUE, independent of price, of OSS, but many others don't. They associate the value with the price tag. Without PAID support, the support is worthless.
Most of the places I've worked have used Red Hat, because it has an enterprise reputation.
Point of clarification: places have RH because they offer support to their enterprise product. Debian's reputation for stability and such is pretty strong, but that only carries so far in the business setting. It's not reputation that drives RH over Deb to the enterprise...it's "I can pay YOU to fix it when it's broke." JMO.
MySQL (the support company) no longer sells support for Debian.
It seems to me that this decision must be driven by sales or market research indicated there is no market for support contracts on Debian based systems. So, does this challenge the notion that OSS can work in a capitalist world when the real "product" is support?
Debian based distros are a significant chunck of the Linux market|mindshare. This decision essentially means the combination of Debian + MySQL is doomed in the business setting.
On the other hand, this does seem to show that there IS a market for support on RH based distros.
In fact, as I think about it, I think what this is really saying is that they want to support MySQL, NOT the underlying OS. Perhaps they have some data that shows that many of their support calls are really for the OS or other parts of the system. In making this decision, they don't rope themselves into having to support anything but MySQL. They can answer a non-relevant (to them) call with "oh, that's an OS issue - call your OS support provider." I'd say that's fair.
It also helps them when there is a problem with MySQL on a client system...THEY can call RH (or whomever) support to make sure everybody gets things 'right.' No, the more I think about it, the more I think this actually strengthens the "give away the software, sell support" model.
Maybe the reason that 99.99% of your problems came from Windows issues is that since you don't use Windows, maybe you just don't know what the hell you're doing when it comes to Windows.
That is almost true. *I* don't know about Windows. That's why my responsibility on the project was only the Linux side of the equation. There was a separate Windows person from the company that supports their Windows computers day-to-day.
Warning: Opinion and Anecdotal discussion to follow; one size does NOT fit all.
All this focus on interoperability is ASSUMING businesses care about operating with Windows. Certainly some do, and they may care about interoperability issues. Others don't; I know my consulting business is a near-nonexistent speck in the grand scheme of things, but I care not one whit about interoperating with Windows. My business is Linux based, and when I set up protocols for dealing with clients, they include cross-platform data formats.
The only time I care about interop with Windows is when a client has a specific need - like the VPN I designed for a client last year. And what I found in that project was 99.99% of ALL the project headaches came from Windows - activation issues, 2003 Server licensing issues, 2003 Server MTU problems, etc.
Anymore, if a client is completely Windows centric and demands a Windows centric solution to their problem, I typically to not even submit a proposal. That's how I view all this interoperability stuff - it is the OTHER players that must conform to the Windows way of doing things; there is no INTERoperability (imho) - it's "operate with Windows' closed way of doing everything, or go play somewhere else."
Well, my business is playing somewhere else. My experience, and those of my clients, is that the solutions I provide LAST and don't force them into Vendor Lock-In and similar, related nonsense. As I said above, this approach is not for everybody.
I used to be a volunteer firefighter and also served as a fire investigator. My experience began around 1981 or so; later (late 90s), I worked for a Police Department doing crime scene work and part of that was fire investigation.
From TFA:
Up until the 1990s, this is what fire investigators were taught:
Fires always burn up, not down.
I was NEVER taught that; just the opposite. Fires tend to burn up FASTER than they burn down, but geez, anyone who has ever actually WATCHED a fire burn knows this statement is nonsense.
Fires that burn very fast are fueled by accelerants; "normal" fires burn slowly.
I was NEVER taught that; just the opposite. We were taught that accelerates were ONE WAY a fire MIGHT burn faster than you would expect under similar conditions. We were also taught that is EXTREMELY difficult to gauge how fast a fire "should have" burned. I did my first chemical test on fire debris in 1986 using GC/MS via a very simple headspace analysis on a sample that the state lab sent back as negative (my test was positive for something, perhaps ambient artifacts, but was an educational run, not an 'official' test). With the negative test result, we sure did not try to use evidence of 'how fast that fired burned' to assert the presence of an accelerant.
Arsons fueled by accelerants burn hotter than "normal" fires.
Somebody is oversimplifying the concept of "fire load" here. There are a WHOLE LOT of things than can make a fire burn hotter than 'normal.' In fact, as a common theme I am trying to represent, "normal" is not a well defined term for real-world fires. Rural firefighters and investigators certainly knew this before 1992.
In fact, this statement glosses over another issue about arson - they often, quite often, don't involve 'accelerants' at all.
The clues to arson are clear. Burn holes on the floor indicate multiple points of origin. Finely cracked glass (called "crazed glass") proves a hotter-than-normal fire. So does the collapse of the springs in bedding or furniture, and the appearance of large blisters on charred wood, known as "alligatoring."
The clues to arson are clear?? Man, I clearly remember in the early 1980's being taught exactly the OPPOSITE of what this article says was the "norm" back then. Perhaps it was taught somewhere, but not in RURAL North Carolina. Absolutely NONE of these "clues" are evidence of arson - only of certain fire conditions.
What we were taught in our arson investigation classes, and what I came to learn through experience, is that arson was/is and EXTREMELY difficult crime to prove. That means it is difficult to prove that a fire was arson, much less who did it.
Truthfully, based on my experience, I don't see the point of this article. It asserts 'beliefs' about fire investigation pre-1992 that just are not true.
And finally, the article gives the tragic story of the Lee family that occured in 1989. While presenting NONE of the evidence that was used to convict him, the story creates the straw man that just because it was 1989 and fire investigation changed (around then, according to the article), he must be framed. I don't know of his guilt or innocence, but that's a might big leap of logic.
Whoa, whoa, whoa, whoa, whoa! Let us not get ahead of ourselves here, the right to bear arms in no way gives anyone a right to kill.
Just what do you think the purpose of "arms" is? To dip in chocolate and eat sweets?
What the GP said is very true...as a LAST resort (and he stated it as such), as in when NOTHING else works. In other words, self defense IS generally thought to be justification for killing, at least within the framework of the US legal system. All that is different in this context is that the aggressor is the government itself.
If something doesn't work, it's not that Linux sucks at compatibility with the world, it's that the user sucks for not investing all their time into making it work.
It is not Linux's responsibility to be compatible with the world. The fact of the matter is there is a boatload of usable softare out there, and some for the iPod, btw, that works Just Fine to Get Things Done in Linux. Stop acting like you HAVE to run Windows software on Linux, and then complain if/when it does not work.
If YOU decide to try software written for one OS work on another OS then YOU must invest the time the 'making it work.' Why in the world, again given that Linux-space applications exist for pretty near everything, would that be someone else's responsibility?
It is a bad idea if you are not a member of the elite, and you are trying to resist tyranny and fight for freedom and human rights via non-violent civil disobedience.
You are making the assumption that the crowd in 'crowd control' automatically implies non-violent. Why would anyone want to deploy ANY weapon, lethal or otherwise, on a crowd of non-violent people?(*) Part of the problem is there seems to be a sliding scale of "non-violent civil disobedience" that sometimes includes throwing rocks at innocent passerby, breaking windows, looting, etc.
In other words, it is POSSIBLE to be FOR freedom and human rights and also see that SOMETIMES, those hiding behind the blanket of 'non-violent civil disobedience' are actually rioting.
(*) I know it DOES happen; in those cases, the OP has a good point and in those cases the arguement is bigger than WHICH weapon is used. My objection is to the overgeneralization that ALL protesting crowds are non-violent, which is certainly not the case.
Uh, this "radiation" is just light, and much LOWER energy than the radiation you see with your eyes. The radiation you fear is much HIGHER energy than visible light. Don't be so quick to kneejerk to the word radiation.
How on earth does subtracting the result from a magic value then give you the inverse square root?
Subtracting the right shifted value from the magic value does NOT give the 'inverse square root.' This line of code only gives the initial guess for the Newton-Raphson algorithm.
While the initial guess is a huge part of the real beauty of the algorithm (ie, why it can converge to a sufficiently accurate value after ONLY ONE ITERATION), the 'real work' is done in the
x = x*( 1.5f - xhalf*x*x )
line. That's that application of one iteration of Newton-Raphson (rewritten a bit from what I and others posted earlier, but for this problem algebraically the same). To get more accuracy in the calculation, apply this line repeatedly.
The explanation of the why the magic value - (right shifted int represenation of the float) is a good initial guess is given in the Paper by Chris Lomont linked to in article. Specifically, look on Section 4 beginning on Page 3 of Lomont's article; that's where the fun starts.
In a nutshell, from Lomont, the initial guess is computed "by multiplying the exponent by -1/2, and then picking bits to minimize error." I have not worked through all the details on why this is a good initial guess, but will reemphasize that getting a good result from Newton-Raphson DEPENDS on the initial guess. So, it is not surprising that someone hunted for a general algorithm to find a good initial guess.
Newton-Raphson is a general algorithm for finding root of an equation f(x)=0.
You start with some INITIAL GUESS (the real beauty of this algorithm) X(0), then apply:
X(n+1) = X(n) - f(X(n)) / f'(X(n))
where
X(n+1) is the NEXT guess after the value you 'know',
X(n) is that most recent value you know,
f(X(n)) is the function evaluated at X(n) and
f'(X(n)) is the first derivative of f(x) evaluated at X(n).
It's not foolproof and a BOTH whether it converges at al AND how FAST it converges depends on the initial guess, X(0)
The "Secant Method" is an improvement that makes it a little 'smarter,' at the expense of more computation (this is often a positive trade-off on numerical modeling codes, since the 'smarter' algorithm does tend to converge faster). There are other improvements as well, such as the Los Alamos Linear Feedback Solver (a slightly modified secant method that converges about 10-17% faster, at least for some types of problems) that I use in my own codes.
Obligatory wikipediea followup: Newton's Method
they've got more business than they can shake a stick at, and it's not going anywhere soon. They have a vested interest in not 'solving' the problem, even if they knew how to do it.
Wow. That simple statement also sums up the War on Drugs.
disclaimer: USED to work in Law Enforcement as part of said "war"...
Yeah. When Apache running on Linux ever breaks through and becomes a highly visible target, LOOK OUT.
Oh wait. That's right. Linux machines ARE visible targets, yet are not pwned in proportion to their use. "Ah," you cry, "but those are servers, not desktops." True. They are servers with purposefully exposed ports and running outside of firewalls; heck, many a Linux Box (PC or embedded) *IS* the firewall for Windows machines. They COULD in principle be compromised and used in botnets like any other computer out there.
The "bigger target, more problems" arguement is flawed. The underlying problem at the system level (ie, not coutnting phishing, physical security problems, etc) is WINDOWS, period. You can argue about whether it is simply the default security model or braindead design all you want, but until that basic reality is accepted, this point of Windows market share is a deflection from the issue.
The team machined a series of barbed rings that extend up the nail's shaft from its point
Boat Nails have been around quite a while; barbs on nails is not new.
disclaimer: no affiliation with linked-to company in any way; just using as a reference.
Are you SERIOUSLY suggesting that short term performance is a better indicated than long term? For long term investments, the 3 month or 1 year is not worth looking at.