OSDev.org

Think of it like this:


Yes, 0.999... is ALMOST 1. Close, but not quite.

But wait. There IS no last 9. So it is infinitely close.

"I am infinitely close to this door" means, well, you're at the door.

Therefore, 0.999... is another representation of 1.

ehird wrote:"I am infinitely close to this door"

means that you are just close..

bubach wrote:

ehird wrote:"I am infinitely close to this door"

means that you are just close..

No, it doesn't. Look up the definition of "infinity" sometime.

It depends on the application whether you use one point of view or another.

http://en.wikipedia.org/wiki/0.999... <-- More info

I still find that the comparisson of (1/3)*3=1 is not fair. All you are doing is reconstructing the original. Actually, if one is going to prove that 0.999...==1.0, no calculator should be used.

As I have already said, any number divided by itself gives 1 always, no matter if decimal, integer, posivite or negative.

So, to test whether 1==0.9999...., try this on your calculator, using it at full cipher capacity:

0.999999999999/1=0.999999999999 (id didn't resulted in 1, it should have been)

1/0.9999999999=1.000000001 (it gave an "infinitely" 0.0000...1, why?)

It looks like the calculator has a workaround and not really gets the 0.99999..==1 result.

Just try to divide 1/3 in your PC, and then push (+) (=), and you will see that you start to get 0.666666666667, and that 7 shouldn't be there.

It clearly demonstrates that our math system is not capable of even representing a 100% accurate value, but that doesn't mean that both numbers are the same.

@ ~:

Note that, for computers, 0.1 is an infinite number, like PI is in "our" math system. What a calculator shows or doesn't show doesn't prove or disprove anything.

Yes, floating point numbers are HIGHLY inaccurate with any kind of computer - don't go there.

And the math system represents numbers at some degree as inaccurately as a calculator.

For example, lets say we want to distribute a box with 10 batteries among 3 devices, each of which needs 3 batteries.

So we have 10/3==3.333333333333.....

Well, as we can see, at most the numeric system is not inaccurate, but it is telling us that when it has an infinitely repetitive cipher, something is missing, not because it's really lost but in reality because we need to take something into account.

In the previous example, it would mean that each of the devices will have 3 batteries, and what about the 10th bettery? We will have to store it, we cannot use it; and it just means that each device only needs 3/10 of the battery package for a total of 9/10. The other 0.333333333.... could be said to be the remaining 1/10, and that representation of infinite decimals would just mean that every device is missing 1/10.

If we store all batteries back, we could say that 0.333333333....*3==9.9999999999999 and accounting the battery we never used we have again a full package (1 unit, 1 box) containing 10 batteries.

As we can see, there were many different ways to represent a same unit value, in real life we would have to take into account a resolution (cm3, molecular, atomic, subatomic?), and whenever we do something like 1/3, that would mean 1 unique object divided in 3 parts. In that case, we can say that for an object with 10 atoms we will only be able to have 3 groups of 3 atoms, and 1 atom would get out of the distribution because it cannot be divided further and would end up in a distribution of 4-3-3 instead of 3-3-3, and yet it doesn't mean this "extra" atom is disregarded or lost but it's up to the actual application how it will be handled.

you guy might interest this
http://en.wikipedia.org/wiki/Riemann_zeta_function

I would say that it's one more part of the mathematical toolset to use in one or another conditions.

I think of it this way:

In a physics engine (or another 3D application), if the wall of object A is in position 0.99999.. and the wall of object B is 1, then the gap in between is infinitely small, and the two objects are considered touching.

If the walls of object A and object B were both 1, then the objects would be overlapping.

I can see a use for this in an application where two numbers must 'touch' (having an infinitely small gap inbetween) without overlapping.

I would normally consider that a rounding error: When doing collision detection, we check wether an object does overlap, and if it does, we move it back to where it can go and then report that we've made contact.

0.9999 would be a problem as the processor cant take an infinite series of 9s - it'lll either get promoted to 1 which either does or does not intersect (depending on definition), or to 0.999998something which is obviously not close enough.

I'm working on a physics engine at the moment, haven't gotten around to collision detection yet but I am going to say this - if you try the following: and obj1.x is 0.9999 and obj2.x is 1 then there is a very high chance that you will not have a match.

Note that I haven't tried this and I may be rambling on about nothing.

pcmattman wrote:I'm working on a physics engine at the moment, haven't gotten around to collision detection yet but I am going to say this - if you try the following:

Code: Select all

if( obj1.x == obj2.x )

and obj1.x is 0.9999 and obj2.x is 1 then there is a very high chance that you will not have a match.

Note that I haven't tried this and I may be rambling on about nothing.

What again was the official information on comparing floats? Never check for equality because of rounding errors.