PDA

View Full Version : do you trust your calculations?

aostling
10-06-2009, 02:28 AM
http://www.youtube.com/watch?v=HGPPwvhWOhQ

 a hoax, but rather well done. Should not have posted.

Black_Moons
10-06-2009, 05:03 AM
heh, I like it.. though yea, most likey a hoax since you can't really calculate a human body going down a slip and slide that accurately. small shift in body position = big change in friction. (Not to mention all the tiny lumps in the ground)

Evan
10-06-2009, 05:15 AM
More importantly the velocity required to make the distance shown is far higher than could be attained even with zero friction over that drop at that angle. Acceleration is equal to the cosine of the angle of the slope times 10 metres per second per second. Then subtract the velocity lost climbing the ramp.

small.planes
10-06-2009, 05:46 AM
<Pedant> Im pretty sure that should be 9.80665 m/s^2 </Pedant>

Its a fun video tho :D

Dave

Evan
10-06-2009, 07:18 AM
On the subject of trusting calculations, should you trust your computer?

Here is a very simple BASIC program:

For k = 0 to 1 step .001
next k

print k

It counts from zero to one in increments of .001. Once it reaches 1 (or more) it then stops and prints the value of the counter, in this instance the variable "k".

The values zero, one and .001 are all rational numbers so no roundoff errors should be expected. However, the result produced is 1.000991 and the number of times the loop executes is 1001, not 1000.

This happens in every version of basic I have ever encountered and is independent of the operating system or the platform used. It is an inherent error in how a computer deals with numbers.

Can anyone explain why?

small.planes
10-06-2009, 08:25 AM
Yes I could, but the first thing I thought of is that computers are metric :p

Dave

Ex Abstract Electron Flow control Engineer

mochinist
10-06-2009, 08:34 AM
These guys aren't fake, maybe not the brightest bunch, but fun to watch anyways:eek:

nitro circus-slip and bleed
http://www.youtube.com/watch?v=J2uGopHIXTs

mattm
10-06-2009, 09:00 AM
On the subject of trusting calculations, should you trust your computer?

Here is a very simple BASIC program:

For k = 0 to 1 step .001
next k

print k

It counts from zero to one in increments of .001. Once it reaches 1 (or more) it then stops and prints the value of the counter, in this instance the variable "k".

The values zero, one and .001 are all rational numbers so no roundoff errors should be expected. However, the result produced is 1.000991 and the number of times the loop executes is 1001, not 1000.

This happens in every version of basic I have ever encountered and is independent of the operating system or the platform used. It is an inherent error in how a computer deals with numbers.

Can anyone explain why?

because you can't precisely represent .001 with a binary floating point number.

Evan
10-06-2009, 09:44 AM
That's correct. Specifically, it can only be represented in binary as an endless repeating number in the same way that 1/3 = .33333333... in decimal.

The binary value for D0.001 is 1.000001100010010011011101001011110001101010011111 10111110011101101100100010110100001110010101100000 01000001100010010011011101001b*10b^-1010b

When you change number bases you change also what numbers can be exactly represented. This can lead to all sorts of problems if you aren't aware of it, especially if you are doing your own math instead of relying on a coprocessor.

Braindead
10-06-2009, 10:15 AM
The OP video is a fairly well known fake, IIRC put together by some wags at Micro\$oft to promote the new Office package.

lazlo
10-06-2009, 10:22 AM
Here is a very simple BASIC program:

For k = 0 to 1 step .001
next k

print k

That's the textbook example of what they teach the kids not to do in Computer Science 101: you can't directly compare floating point numbers.

The correct way to compare floating point numbers is with an absolute or relative error.

Absolute Error:

epsilon = 0.00001
if (fabs(result - expectedResult) < epsilon)

Relative Error:

relativeError = fabs((result - expectedResult) / expectedResult);

Evan
10-06-2009, 10:44 AM
Even when using old BASIC implementations all you need to do is multiply by the precision factor, then do the math as integers, then divide again.

Paul Alciatore
10-06-2009, 10:59 AM
Re: Evan's program error. It's not the fact that it is "floating point" that is the source of the error. If you built a floating point processor that operated in decimal numbers, and yes it could be done, then it would work OK as long as you had a decimal precision to at least three decimal places built into it.

The actual error comes about, as Evan says, due to the fact that all computers work with binary and the number 0.001 can not be expressed without using an infinite decimal. Because the computer's numbers can not be infinitely long, there is a rounding error at each iteration through the loop and it winds up a bit short after 1000 iterations. Thus, it needs one more or 1001 times to finally end the loop.

The easy way to avoid the problem is to change it to

For n = 1 to 1000 Step 1

If you don't specify the use of interer math, this will use the same floating point numbers, but it avoids the rounding error because binary numbers can represent the number 1 exactly, without any rounding error (1 decimal = 1 binary, exactly).

Also,

For n = 1 to 125 Step 0.125

should also work as binary numbers can represent 0.125 exactly, without using an infinite decimal (0.125 decimal = 0.001 binary, exactly). So there is no rounding error.

It's not the floating point math, it is the binary math that is the "problem".

Evan
10-06-2009, 11:04 AM
The 6502 series processors actually have a decimal mode in which all operations are done in binary coded decimal.

TheAndroid
10-06-2009, 11:53 AM
As do all of the IBM 360 - 390 series processors (Packed Format is a compressed signed BCD form). They are used precisely because of the inaccuracy of binary representation.

BCD has always been representable on Intel x86 hardware, but most if not all compiler and interpreter vendors don't use it because there were few native mathematical operations supported on the chip. Thus, everything had to be done in software and at 4.77 mhz, that was too slow.

Floats are usually represented internally in the exponent mantissa form of (I believe) IEEE-754 which states 80 bits total to hold the value. There are other forms (short floats - 64 bits, long floats - 128 bits) but they still suffer from the limitations of the representation.

Astronowanabe
10-06-2009, 12:12 PM
On the subject of trusting calculations, should you trust your computer?

Here is a very simple BASIC program:

For k = 0 to 1 step .001
next k

print k

It counts from zero to one in increments of .001. Once it reaches 1 (or more) it then stops and prints the value of the counter, in this instance the variable "k".

The values zero, one and .001 are all rational numbers so no roundoff errors should be expected. However, the result produced is 1.000991 and the number of times the loop executes is 1001, not 1000.

This happens in every version of basic I have ever encountered and is independent of the operating system or the platform used. It is an inherent error in how a computer deals with numbers.

Can anyone explain why?

why yes, ultimately it is because a set cannot be mapped onto the set of all of it's subsets. but that is a bit too abstract to be useful in making bits nevermind chips.

A useful explanation for bits has already been done quite well here:

http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf

and to compensate while making chips I just lean against the carriage.

lazlo
10-06-2009, 12:42 PM
Re: Evan's program error. It's not the fact that it is "floating point" that is the source of the error. If you built a floating point processor that operated in decimal numbers, and yes it could be done, then it would work OK as long as you had a decimal precision to at least three decimal places built into it.
It's not the floating point math, it is the binary math that is the "problem

The error is the round-off error you get because the numbers are represented as Floating Point numbers. Decimal fractions are almost always represented as floating-point numbers.
As Android correctly notes, although most modern processors (including Intel) support BCD format, but do the calculations in microcode, so it's very slow.

So the compiler will cast two floats for that code snippet: K as a floating point variable, and .001 as a floating point constant.

0.001 in floating point notation is 1.00 x 10-3

Floats are usually represented internally in the exponent mantissa form of (I believe) IEEE-754 which states 80 bits total to hold the value. There are other forms (short floats - 64 bits, long floats - 128 bits) but they still suffer from the limitations of the representation.

IEEE 754 formats:

Single Precision Float = 32 bits: 23-bit mantissa, 8-bit exponent, sign bit.
Double Precision Float = 64 bits: 52-bit mantissa, 11-bit exponent, sign bit.
Intel's Extended Precision Float: 80 bits. (I don't remember the format off-hand).

dp
10-06-2009, 12:58 PM
The only floating point in the OP was photoshop'd, but it's still funny!

juergenwt
10-06-2009, 01:21 PM
A nice fake for Microsoft: http://www.microsoft.com/germany/aktionen/mach-es-machbar/default.aspx

Evan
10-06-2009, 01:22 PM
This is my favorite Microsoft ad.

http://www.allowe.com/Humor/video/Microsoft,OfficeXPSex.mpeg

lazlo
10-06-2009, 02:20 PM
Another famous YouTube hoax:

http://www.youtube.com/v/VFGVzt7c5bY&hl=en&fs=1&