0.99999... != 1

ehird · Post by **ehird** » Fri Mar 16, 2007 2:10 pm

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.

bubach · Post by **bubach** » Fri Mar 16, 2007 5:48 pm

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

means that you are just close..

ehird · Post by **ehird** » Sat Mar 17, 2007 9:55 am

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.

~ · Post by ~ » Sat Mar 17, 2007 10:04 am

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

ehird · Post by **ehird** » Sat Mar 17, 2007 10:16 am

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

~ · Post by ~ » Sat Mar 17, 2007 10:27 am

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.

Solar · Post by **Solar** » Sat Mar 17, 2007 10:37 am

@ ~:

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.

ehird · Post by **ehird** » Sat Mar 17, 2007 10:47 am

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

~ · Post by ~ » Sat Mar 17, 2007 11:06 am

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.

binutils · Post by **binutils** » Thu Apr 05, 2007 6:13 am

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

~ · Post by ~ » Thu Apr 05, 2007 7:19 am

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

AndrewAPrice · Post by **AndrewAPrice** » Thu Apr 05, 2007 9:57 pm

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.

Combuster · Post by **Combuster** » Fri Apr 06, 2007 3:45 am

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.

pcmattman · Post by **pcmattman** » Fri Apr 06, 2007 4:24 am

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.

Candy · Post by **Candy** » Sat Apr 07, 2007 4:33 am

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.