He borrows my car once a month to drive his grandma to do her monthly shopping and she usually gives him some money.
I hope you checked that your insurance covers this. Would be sad if grandma is involved in an accident and no insurance covers the cost. It might mean financial ruin for your friend and his grandma.
I agree with everything else you're saying, but this is absolutely false. AIDS is VERY difficult to get. You won't get AIDS from casual contact with saliva, urine, sputum, or feces. Ebola can be contracted by any of these coming in contact with your eye.
Someone with AIDS can pass the disease on for many years. Someone with Ebola can pass it on for 21 days.
If I called up the FBI and told them that I had anthrax in my basement they'd send in a small army. If I called up the CDC and told them that I had lunch with the guy who had Ebola they'd tell me to stay home and call them if I get a fever. Maybe we should be less worried about saving money, and more worried about whether I decide I get tired of staying home and just make one quick trip to the grocery store.
If you had anthrax in your basement, you would most likely be a dangerous nutcase you could do untold damage. If you had lunch with the guy who had Ebola, the assumption would be that you are a normal upstanding godfearing citizen who knows that if they leave their apartment after being told to stay and someone dies because of that they would get hit with a manslaughter charge.
Is copyright infringement actually "illegal", or is it just a civil matter between copyright holder and infringer?
It's illegal. Depending on the situation, it may or may not be a crime. It may be just a civil matter between copyright holder and infringer, but it's still illegal.
It's illegal to upload music to USENET, but it sure as hell isn't illegal to download it from there.
Please note that my examples were about the copyright holders themselves uploading music or other copyrighted works, and giving people permission to download for free. Saying something like "it's illegal to upload" is stupid when you don't qualify it like "without the user's permission".
Note that downloading music from USENET or anywhere without the permission of the copyright holder is illegal. Depending on the situation, it might not be a crime while the uploading is more likely to be a crime, but it is nevertheless illegal without permission of the copyright holder or something else that allows it.
Xcode using a recent version of Clang with the standard library supplied by Clang does the following:
1. The long double function sinl uses the FSIN instruction, except it checks when the argument is too large (> 2^63) and does an argument reduction using a 64 bit approximation of pi.
2. The double function sin uses SSE register and floating point arithmetic, using argument reduction with a value > 100 bits for pi.
First, it's an x87 instruction. This unit has been deprecated for a decade.
It's not deprecated at all. It's commonly used by everyone using "long double" instead of "double" in their x86 code. And using "long double" can be very useful. For example, if you want to write a function that calculates sqrt (x^2 + y^2) for double precision x and y, that's very very hard to get right using double precision only, but using long double in the calculation and rounding to double makes it trivial.
(If you want to know why this would be hard to get right, consider what happens if x, y are around 1e200 or 1e-200. In many implementations, it is possible that x >= x' > 0, y >= y' > 0, but the result for x, y is less than the result for x', y').
The FSIN instruction is actually accurate to better (quite a bit better) than one ULP... for the first quadrant. So they're not actually saving any CPU cycles by this "approximation".
If you calculate y = FSIN (x), then within the first quadrant y is within one ULP from the exact value sin (x). However, for _all_ values x, y will be equal to sin (x') for some number x' that is within one ULP from x.
I know nothing of processing, at least at this level. You often post good stuff here. Can you explain why computer processors cannot do the functions in the same way that calculators do? Maybe I'm asking the question in the wrong way, but you know what I mean (I hope).
The whole problem is that you may have been reading an article written by a blogger who made some rather idiotic assumptions about the precision of the sine function.
Here's the reality: If you look at posts on stackoverflow.com you will find to your horror that many "programmers" apparently don't even know the difference between "float" and "double" and do calculations with six digits precision instead of 15, out of stupidity. Intel processors also support "extended precision" which gives you >18 digits precision if you use long double; fact is that during the PowerPC era Macs didn't support this, and nobody complained! The blogger actually complains that the FSIN instruction doesn't use an infinitely precise value of pi, but one that is rounded to 66 bit (2 bits more than extended precision). Fact is that FSIN uses two bits more than you could use if you tried to implement the sine function yourself in extended precision, so 99.99% of all people trying to implement this themselves would end up with an implementation that is worse than FSIN.
It seems that the blogger didn't actually read the documentation that he claimed to read. The exact behaviour is documented in "Intel® 64 and IA-32 Architectures Software Developerâ(TM)s Manual
Volume 1: Basic Architecture" of March 2012 on page 8-31. I don't have an older copy of that manual anymore, but I have written code according to that exact documentation sometime around 2001, so I am quite confident that it was in the 2001 version of the document.
This is what the documentation says: "The internal value of Ï that the x87 FPU uses for argument reduction and other computations is as follows: Ï = 0.f â-- 2^2 where: f = C90FDAA2 2168C234 C". A more precise approximation according to Wikipedia would have been f = C90FDAA2 2168C234 C4C6 4...; the difference between pi and the approximation used by Intel is about 0.0764 * 2^-64.
If you let x = pi, then people would ordinarily expect that sin (x) = 0. That, however, would be wrong. Storing pi into a floating-point number produces a rounding error. Rounded to extended precision (64 bit mantissa) instead of the usual double precision (53 bit mantissa) produces a result of 4 * 0.C90FDAA2 2168C235 instead of 4 x C90FDAA2 2168C234 C4C6 4...; this is too large by 4 * (1 - 0.C4C64...) * 2^-64. The sine of that number would also be 4 * (1 - 0.C4C64...) * 2^-64.
But FSIN doesn't subtract pi from that number x, instead it subtracts 4 * 0.C90FDAA2 2168C234 C. So we get a result of 4 * (1 - 0.C) * 2^-64 instead of 4 * (1 - 0.C4C64...) * 2^-64. That's what he complains about. The reality is that the correct result would have been zero, but we couldn't get that because trying to assign pi even to an extended precision number gives some rounding error.
Now in practice, if you calculate an argument for the sine function, and that argument is close to pi, even if you manage to get a correctly rounded extended precision result, you must expect a rounding error up to 2^-63, and therefore an error in the result up to 2^-63, even if the calculation of the result is perfect. FSIN gives a result that is about 0.0764 * 2^-64 away from that, so the inevitable error caused by rounding the argument is increased by a massive 3.82 percent. Doing the calculation in double precision, as almost everyone does, makes the rounding error 2048 times larger and FSIN is now 0.00185 percent worse than optimal.
I'm not sure that this is even true - the way I understand it, nobody even knows how many operations it takes in the general case, if by "fully approximating sine" you mean "returning a result no more than half-ulp from the correct value for every valid input".
That's actually solved (for double precision). Google for crlibm.
So use hardware floating point operations when it doesn't matter, like for games. But if you're going to calculate the trajectory of a mission to Pluto or something, bring the math out into your software, take the time, do it right.
Forget it. _You_ can't write an implementation of the sine function that is more precise than FSIN. Apple's implementation on PowerPC was more accurate; Java VMs must have a more precise implementation to pass Sun's compatibility tests. But anyone who knows about "Taylor polynomials" or "Pade approximations" or "CORDIC" will end up with something less precise.
I recall working with numerical methods from about 40 years ago, and all of the calculations that required a call to sin were range reduced to the region of +/- pi/4 anyway. The reason is that the taylor series expansions for sine and cos are most accurate in the region of zero, and for values in excess of pi/4, it is more accurate to do a transformation and implement a different call.
If you read the article, that's what the Intel processor does. Instead of an infinitely precise value of pi, it uses pi rounded to 66 bits (which is 13 bits more than normal double precision arithmetic would use, and 2 bits more than extended precision arithmetic would use). So all these people getting all excited about an error in Intel's FPU most likely wouldn't be capable of implementing the sine function anywhere near as precise as FSIN does.
That number 1.5707963267948966193 is a decimal number. Before you get anywhere near calculating the tangent of that number, you have to convert it to a binary number. The error in that conversion will be about 2^-64. That means the argument that you pass to the FTAN instruction isn't actually 1.5707963267948966193, but a number that is different from this by up to 2^-64. The error that you get by not passing 1.5707963267948966193 but a slightly different number is about ten times larger than the error in the FTAN function.
Here's what the complaint is about: The Intel FSIN instruction performs an argument reduction to calculate the values of the sine function, but not with the exact value of pi, but using a 66 bit approximation of pi. If your argument is close to a multiple of pi, then the argument reduction doesn't give the correct result.
HOWEVER, if your argument is an extended precision number close to pi = 3.14..., then the last bit in the mantissa of that number has a value of 2^-62. So if you calculate an argument close to pi, the unavoidable bounds for the rounding error are 2^-63. This error in the argument is about 10 times larger than the error caused by using an approximation for pi in the argument reduction. If you use double precision, the error in the argument is about 20,000 times larger than the error caused by the argument reduction.
All this has been known for years; posting it today and claiming there is any problem is just ridiculous.
Downloading free music is perfectly legal. Apple just claimed that 23 million people downloaded a free U2 album. That's perfectly legal. I've probably downloaded about 500 songs that were free. Legally. Quite a few books and audiobooks as well.
Apple and Amazon will be surprised to hear that downloading music is stealing. On the other hand, it's fine with the FBI if I lend my backup drive to friends so they can copy my complete collection of music, since clearly this isn't downloading?
Ever been Swatted? A friend of mine was swatted twice.
Personally, I think this is so dangerous that it should be treated as attempted murder, and the police should treat it accordingly. Unless an accident happens and someone dies, in which case it is obviously murder.
I wonder if that actually happens? There should be recordings of the call, which could be published on TV, with a good chance of being recognised.
That would reward criminal actions of law enforcement officials. There are good reasons why illegally obtained evidence cannot be used in court.
Just to clarify: The reason for all this is _not_ to prevent criminals to get away with crimes if the police misbehaves, the reason is to protect innocent citizens from police misbehaviour.
The police must be punished for breaking the law. However, so to must OTHER criminals they have uncovered... even if the evidence was obtained illegally.
That's not how it works. The police is punished for illegal searches by making the results of the illegal search not usable as evidence, or as a reason for further investigation. That's it. It was decided that this is the proper way to stop the police from making illegal searches against innocent citizens.
It's also quite obvious that a police officer may make an illegal search by mistake. If the result of such a search could be used, you would expect police officers in getting more clever making illegal searches "by mistake", so we look just at the fact that it was an illegal search and not further.
In your example, over 1,000 miles 30 to 35 mpg saves you 4.76 gallons. 10 to 15 mpg saves you 33.33 gallons.
Now let's say you want to visit your old auntie who lives a long distance away. With the same fuel/money you can visit her 7 instead of 6 times going from 30 to 35 mpg. Or 3 instead of 2 times going from 10 to 15 mpg.
Bought the car, great price, 0% financing... quite honestly it was a dream to purchase. I drove it home and was very happy with the 38MPG sticker on the window. I never expected 38... but 33 surely should be reasonable right? Wrong. My first tank I calculated at 24MPG. 24!!!!!!! I called into the dealer and was informed that the new boosted motors require a break in period of about 3,000 miles before they start to get better mileage. After 4,000 miles my best tank was 26MPG. At 6,000 miles I was getting almost 28 when I drove like an old lady. Today that's where my MPG sits.... 28. The car is amazing and I love getting into it every morning but the mileage I get completely screws my cost of ownership numbers. I've learned to live with the shit mileage (my last Honda 2 door got 35mpg) and the car still won't be a loss on my 10 year figures especially with the 0% financing I was able to snag. Just every time I fill the tank I feel like I've been screwed a little.
I'm told that modern Diesel engines will once in a while (10,000 miles or so) enter a special mode where they deliberately produce more heat to clean up things around the engine (particle filters I think, not sure). When that happens your mileage goes down horribly for a dozen miles or two, but after that it's fine again .
What matters to me is that my gas gauge says 1/4 tank, I'm about 150 miles from home and it is almost midnight and all the gas stations between where I am and where I'm going will be closing soon. Now do I need to get gas at the station up ahead, even though it is way more expensive than in my home town?
Most people have a button on the dashboard that will tell them how far they can still go. Mine is a bit dodgy just after you fill up, it displays 500 miles for a long time until it starts going down 1 mile for each mile you drive.
Slashdot Mirror
He borrows my car once a month to drive his grandma to do her monthly shopping and she usually gives him some money.
I hope you checked that your insurance covers this. Would be sad if grandma is involved in an accident and no insurance covers the cost. It might mean financial ruin for your friend and his grandma.
I agree with everything else you're saying, but this is absolutely false. AIDS is VERY difficult to get. You won't get AIDS from casual contact with saliva, urine, sputum, or feces. Ebola can be contracted by any of these coming in contact with your eye.
Someone with AIDS can pass the disease on for many years. Someone with Ebola can pass it on for 21 days.
If I called up the FBI and told them that I had anthrax in my basement they'd send in a small army. If I called up the CDC and told them that I had lunch with the guy who had Ebola they'd tell me to stay home and call them if I get a fever. Maybe we should be less worried about saving money, and more worried about whether I decide I get tired of staying home and just make one quick trip to the grocery store.
If you had anthrax in your basement, you would most likely be a dangerous nutcase you could do untold damage. If you had lunch with the guy who had Ebola, the assumption would be that you are a normal upstanding godfearing citizen who knows that if they leave their apartment after being told to stay and someone dies because of that they would get hit with a manslaughter charge.
Is copyright infringement actually "illegal", or is it just a civil matter between copyright holder and infringer?
It's illegal. Depending on the situation, it may or may not be a crime. It may be just a civil matter between copyright holder and infringer, but it's still illegal.
It's illegal to upload music to USENET, but it sure as hell isn't illegal to download it from there.
Please note that my examples were about the copyright holders themselves uploading music or other copyrighted works, and giving people permission to download for free. Saying something like "it's illegal to upload" is stupid when you don't qualify it like "without the user's permission".
Note that downloading music from USENET or anywhere without the permission of the copyright holder is illegal. Depending on the situation, it might not be a crime while the uploading is more likely to be a crime, but it is nevertheless illegal without permission of the copyright holder or something else that allows it.
Xcode using a recent version of Clang with the standard library supplied by Clang does the following:
1. The long double function sinl uses the FSIN instruction, except it checks when the argument is too large (> 2^63) and does an argument reduction using a 64 bit approximation of pi.
2. The double function sin uses SSE register and floating point arithmetic, using argument reduction with a value > 100 bits for pi.
First, it's an x87 instruction. This unit has been deprecated for a decade.
It's not deprecated at all. It's commonly used by everyone using "long double" instead of "double" in their x86 code. And using "long double" can be very useful. For example, if you want to write a function that calculates sqrt (x^2 + y^2) for double precision x and y, that's very very hard to get right using double precision only, but using long double in the calculation and rounding to double makes it trivial.
(If you want to know why this would be hard to get right, consider what happens if x, y are around 1e200 or 1e-200. In many implementations, it is possible that x >= x' > 0, y >= y' > 0, but the result for x, y is less than the result for x', y').
The FSIN instruction is actually accurate to better (quite a bit better) than one ULP ... for the first quadrant. So they're not actually saving any CPU cycles by this "approximation".
If you calculate y = FSIN (x), then within the first quadrant y is within one ULP from the exact value sin (x). However, for _all_ values x, y will be equal to sin (x') for some number x' that is within one ULP from x.
I know nothing of processing, at least at this level. You often post good stuff here. Can you explain why computer processors cannot do the functions in the same way that calculators do? Maybe I'm asking the question in the wrong way, but you know what I mean (I hope).
The whole problem is that you may have been reading an article written by a blogger who made some rather idiotic assumptions about the precision of the sine function.
Here's the reality: If you look at posts on stackoverflow.com you will find to your horror that many "programmers" apparently don't even know the difference between "float" and "double" and do calculations with six digits precision instead of 15, out of stupidity. Intel processors also support "extended precision" which gives you >18 digits precision if you use long double; fact is that during the PowerPC era Macs didn't support this, and nobody complained! The blogger actually complains that the FSIN instruction doesn't use an infinitely precise value of pi, but one that is rounded to 66 bit (2 bits more than extended precision). Fact is that FSIN uses two bits more than you could use if you tried to implement the sine function yourself in extended precision, so 99.99% of all people trying to implement this themselves would end up with an implementation that is worse than FSIN.
You apparently cannot reed.
That makes me wonder if you made a very clever joke, or weather you can't right.
It seems that the blogger didn't actually read the documentation that he claimed to read. The exact behaviour is documented in "Intel® 64 and IA-32 Architectures Software Developerâ(TM)s Manual Volume 1: Basic Architecture" of March 2012 on page 8-31. I don't have an older copy of that manual anymore, but I have written code according to that exact documentation sometime around 2001, so I am quite confident that it was in the 2001 version of the document.
This is what the documentation says: "The internal value of Ï that the x87 FPU uses for argument reduction and other computations is as follows: Ï = 0.f â-- 2^2 where: f = C90FDAA2 2168C234 C". A more precise approximation according to Wikipedia would have been f = C90FDAA2 2168C234 C4C6 4...; the difference between pi and the approximation used by Intel is about 0.0764 * 2^-64.
If you let x = pi, then people would ordinarily expect that sin (x) = 0. That, however, would be wrong. Storing pi into a floating-point number produces a rounding error. Rounded to extended precision (64 bit mantissa) instead of the usual double precision (53 bit mantissa) produces a result of 4 * 0.C90FDAA2 2168C235 instead of 4 x C90FDAA2 2168C234 C4C6 4...; this is too large by 4 * (1 - 0.C4C64...) * 2^-64. The sine of that number would also be 4 * (1 - 0.C4C64...) * 2^-64.
But FSIN doesn't subtract pi from that number x, instead it subtracts 4 * 0.C90FDAA2 2168C234 C. So we get a result of 4 * (1 - 0.C) * 2^-64 instead of 4 * (1 - 0.C4C64...) * 2^-64. That's what he complains about. The reality is that the correct result would have been zero, but we couldn't get that because trying to assign pi even to an extended precision number gives some rounding error.
Now in practice, if you calculate an argument for the sine function, and that argument is close to pi, even if you manage to get a correctly rounded extended precision result, you must expect a rounding error up to 2^-63, and therefore an error in the result up to 2^-63, even if the calculation of the result is perfect. FSIN gives a result that is about 0.0764 * 2^-64 away from that, so the inevitable error caused by rounding the argument is increased by a massive 3.82 percent. Doing the calculation in double precision, as almost everyone does, makes the rounding error 2048 times larger and FSIN is now 0.00185 percent worse than optimal.
I'm not sure that this is even true - the way I understand it, nobody even knows how many operations it takes in the general case, if by "fully approximating sine" you mean "returning a result no more than half-ulp from the correct value for every valid input".
That's actually solved (for double precision). Google for crlibm.
So use hardware floating point operations when it doesn't matter, like for games. But if you're going to calculate the trajectory of a mission to Pluto or something, bring the math out into your software, take the time, do it right.
Forget it. _You_ can't write an implementation of the sine function that is more precise than FSIN. Apple's implementation on PowerPC was more accurate; Java VMs must have a more precise implementation to pass Sun's compatibility tests. But anyone who knows about "Taylor polynomials" or "Pade approximations" or "CORDIC" will end up with something less precise.
I recall working with numerical methods from about 40 years ago, and all of the calculations that required a call to sin were range reduced to the region of +/- pi/4 anyway. The reason is that the taylor series expansions for sine and cos are most accurate in the region of zero, and for values in excess of pi/4, it is more accurate to do a transformation and implement a different call.
If you read the article, that's what the Intel processor does. Instead of an infinitely precise value of pi, it uses pi rounded to 66 bits (which is 13 bits more than normal double precision arithmetic would use, and 2 bits more than extended precision arithmetic would use). So all these people getting all excited about an error in Intel's FPU most likely wouldn't be capable of implementing the sine function anywhere near as precise as FSIN does.
tan(1.5707963267948966193)
And the example is rubbish.
That number 1.5707963267948966193 is a decimal number. Before you get anywhere near calculating the tangent of that number, you have to convert it to a binary number. The error in that conversion will be about 2^-64. That means the argument that you pass to the FTAN instruction isn't actually 1.5707963267948966193, but a number that is different from this by up to 2^-64. The error that you get by not passing 1.5707963267948966193 but a slightly different number is about ten times larger than the error in the FTAN function.
Here's what the complaint is about: The Intel FSIN instruction performs an argument reduction to calculate the values of the sine function, but not with the exact value of pi, but using a 66 bit approximation of pi. If your argument is close to a multiple of pi, then the argument reduction doesn't give the correct result.
HOWEVER, if your argument is an extended precision number close to pi = 3.14..., then the last bit in the mantissa of that number has a value of 2^-62. So if you calculate an argument close to pi, the unavoidable bounds for the rounding error are 2^-63. This error in the argument is about 10 times larger than the error caused by using an approximation for pi in the argument reduction. If you use double precision, the error in the argument is about 20,000 times larger than the error caused by the argument reduction.
All this has been known for years; posting it today and claiming there is any problem is just ridiculous.
Should these guys really release 200,000 pictures, they would owe the copyright holders up to $30bn dollars in stautory damages if convicted.
Downloading free music is perfectly legal. Apple just claimed that 23 million people downloaded a free U2 album. That's perfectly legal. I've probably downloaded about 500 songs that were free. Legally. Quite a few books and audiobooks as well.
There are tons of free books at http://www.gutenberg.org/ and tons of free audiobooks at librivox.org . JSB's complete works for organ at http://www.blockmrecords.org/b... .
I would have hoped that the FBI would know the difference between "free" and "illegal".
Apple and Amazon will be surprised to hear that downloading music is stealing. On the other hand, it's fine with the FBI if I lend my backup drive to friends so they can copy my complete collection of music, since clearly this isn't downloading?
Ever been Swatted? A friend of mine was swatted twice.
Personally, I think this is so dangerous that it should be treated as attempted murder, and the police should treat it accordingly. Unless an accident happens and someone dies, in which case it is obviously murder.
I wonder if that actually happens? There should be recordings of the call, which could be published on TV, with a good chance of being recognised.
That would reward criminal actions of law enforcement officials. There are good reasons why illegally obtained evidence cannot be used in court.
Just to clarify: The reason for all this is _not_ to prevent criminals to get away with crimes if the police misbehaves, the reason is to protect innocent citizens from police misbehaviour.
The police must be punished for breaking the law. However, so to must OTHER criminals they have uncovered... even if the evidence was obtained illegally.
That's not how it works. The police is punished for illegal searches by making the results of the illegal search not usable as evidence, or as a reason for further investigation. That's it. It was decided that this is the proper way to stop the police from making illegal searches against innocent citizens.
It's also quite obvious that a police officer may make an illegal search by mistake. If the result of such a search could be used, you would expect police officers in getting more clever making illegal searches "by mistake", so we look just at the fact that it was an illegal search and not further.
In your example, over 1,000 miles 30 to 35 mpg saves you 4.76 gallons. 10 to 15 mpg saves you 33.33 gallons.
Now let's say you want to visit your old auntie who lives a long distance away. With the same fuel/money you can visit her 7 instead of 6 times going from 30 to 35 mpg. Or 3 instead of 2 times going from 10 to 15 mpg.
Bought the car, great price, 0% financing... quite honestly it was a dream to purchase. I drove it home and was very happy with the 38MPG sticker on the window. I never expected 38... but 33 surely should be reasonable right? Wrong. My first tank I calculated at 24MPG. 24!!!!!!! I called into the dealer and was informed that the new boosted motors require a break in period of about 3,000 miles before they start to get better mileage. After 4,000 miles my best tank was 26MPG. At 6,000 miles I was getting almost 28 when I drove like an old lady. Today that's where my MPG sits.... 28. The car is amazing and I love getting into it every morning but the mileage I get completely screws my cost of ownership numbers. I've learned to live with the shit mileage (my last Honda 2 door got 35mpg) and the car still won't be a loss on my 10 year figures especially with the 0% financing I was able to snag. Just every time I fill the tank I feel like I've been screwed a little.
I'm told that modern Diesel engines will once in a while (10,000 miles or so) enter a special mode where they deliberately produce more heat to clean up things around the engine (particle filters I think, not sure). When that happens your mileage goes down horribly for a dozen miles or two, but after that it's fine again .
What matters to me is that my gas gauge says 1/4 tank, I'm about 150 miles from home and it is almost midnight and all the gas stations between where I am and where I'm going will be closing soon. Now do I need to get gas at the station up ahead, even though it is way more expensive than in my home town?
Most people have a button on the dashboard that will tell them how far they can still go. Mine is a bit dodgy just after you fill up, it displays 500 miles for a long time until it starts going down 1 mile for each mile you drive.