Thread: Possible to make a program that divides to an infinite decimal place?

Originally Posted by Brad0407

Sure you can
_ _
1 - .9 = .01

1.00000000000...
- .99999999999....
-----------------------
.000000000...1

No.

Absolutely not.

For one, you're implying that the '1' in the answer will be at the end - but the end never comes! The number of decimal places you're representing is infinite. Meaning, there is no limit or end to it, so no place to put your one.

The issue at hand for the post you're refering to claimed (correctly) that:
1) Between every two rational numbers, there is another rational number, and
2) Since there is no number between .9999... and 1, they are, in fact, the same number.

Finding a difference (subtracting) between two numbers is a good way to show they are not equal. So, for the sake of argument, let's pretend your 'calculation' above is valid:

Assume: 1-.9999.... = .0000...1 (A string of infinite zeros with a one at the 'end' - the infiniteth decimal place?)
I'll represent .000....1 as 'd' for the remainder of this post for two reasons:

1) To shorten it
2) It makes me ill

d's construction implies that it is the rational number with the smallest absolute value. I'm not going to get into it here, I can only take so much fake math in one day.

From here we can take a number of paths, but here is the quickest (and most fun):

If d is a rational number, and 0 is a rational number, then one of two things is true:

1) There is a number between them.
2) They are equal.

Since d is the rational number with the smallest absolute value, it is the closest to 0, which implies that there is no number between d and 0 (since if there were, it would be the number with the smallest absolute value). Since there is no number between 0 and d, they must be equal!

So, unfortunately, your post is not only wrong, but even if it were right, it would be wrong.

Note: This is not a flame. The infinite and its consequences are thing to get your head around. I'm just trying to explain a little of it.

It may eventually take an infinite amount of time but only when it reaches the infinite digit and since infinity is a concept not a real number, there will always be a next number. It will simply take the computer time. The calculations are the only thing that hold you back because the preprogramed calculations require the whole number and that would take an infinite amount of memory. The calculations only need a single digit at a time so if I write my on digit-based calculations, I can eliminate that problem. In the end, I only need to know if the digit I added made the square go over 2 and if it did then I take the next smallest digit. There will be alot of recusive functions in this one.

At the crux of this debate is the misuse and misunderstanding of infinite.

I believe what the OP asked, and what Brad0407 is attempting, is a program that will calculate as many decimal places as the user requests. This is an entirely different beast than calculating an infinite amount of decimal places. Calcluating an infinite amount of decimal places will take an infinite amount of time, because as Brad0407 stated, there will always be another number.

The best we can do is to create a program that approximates a fraction to any decimal place. Now this number will be limited by the hardware it's run on, and a truly infinite calculation is impossible. However - with such an algorithm, we can achieve any level of accuracy we request.

The goal of my program is to continue running forever which is the concept of infinity and as long as I don't have to actually store the entire number and all I have to do is display the digits one at a time, then I can work with only a few single digit numbers at a time. I will then delete them when I'm done with them and the program will display numbers forever and in effect the program will figure an infinite number of decimals. The more decimals, the more time the program will take to come up with the next one but it will always come up with a next number. In doing so the program itself is figuring to an infinite number of decimal places in theory but in reality will never reach it because I don't plan on leaving the program running for eternity.

Before I'm stuck at home with my unbelievably slow internet connection, I had an idea for this program, and wanted to see what you guys (and girls) think. I haven't compiled or tested it since I don't have a compiler at work, but I think it will do the trick:

Code:

#include <iostream>

using namespace std;

int divide(int&, int&);

int main()
{
    int num, denom;
    int places;           //I know ints have a limit, but I don't know what kind of variable
                               //to use to ensure any number can be used

    cout << "Enter the numerator, denominator, and desired number of decimal places: ";
    cin << num, denom, places;
    cout << endl << "The answer is: " << divide(num, denom) << ".";

    for (int i = 0; i !=places; ++i)
        cout << divide(num, denom);
 
    return 0;
}

int divide(int& num, int& denom)
{
    int ret;
    ret = denom / num;
    denom = (denom - (num * ret)) * 10;

    return ret;
}

I'm kind of going out on a limb since I haven't tested it, but the algorithm should be what we're looking for.

I finally got around to writing the code to divide to an infinite digit. Not that if you want it to stop at a certain point, you can enter the number of digits that you want. Otherwise put in 0. Anyway, here's the code:

Code:

#include <iostream>

using namespace std;

int main()
{
	int num;
	int den;
	int dec;
	int rem;
	int index;

	cout << "Enter numerator: ";
	cin >> num;
	cout << "Enter denominator: ";
	cin >> den;
	cout << "Enter number of decimal places: ";
	cin >> dec;

	cout << num/den << ".";
	rem = ( (num % den) * 10);

	if(dec > 0)
	{
		for(index = 0; index < dec; index++)
		{
			cout << rem/den;
			rem = ( (rem % den) * 10);
		}
	}
	else
	{
		while(1)
		{
			cout << rem/den;
			rem = ( (rem % den) * 10);
		}
	}

	cout << endl;
	return 0;
}

Enjoy!

Or just run it on a really slow computer.

now we also know that the chance that a random number A is bigger than a random number B is 50%.

You can't just assume things like this.

For example, suppose you were to pick a random positive integer. What is the probability that the integer you picked is even? Some of you might answer "50%"; that's the intuitive answer. But what if you write down the integers like this?

1
3 2
5 4 6
7 8 10 12
9 14 16 18 20
11 22 24 26 28 30
... ...

It looks to me like the odd numbers occupy only a small fraction of that sequence. (You'll find that the proportion converges towards zero as the sequence grows arbitrarily long.)

In order to talk about probability, you need some exact way of measuring probability. For example, if you take an infinite sequence of intervals [1,1], [1,2], [1,3], [1,4], ... and for each interval calculate the proportion of even numbers, you'll get a sequence that looks something like 0, 1/2, 1/3, 1/2, 2/5, 1/2, 3/7, 1/2, ..., which converges on 1/2. This would be one way of measuring probability when picking positive integers that gives intuitive results. For example, this form of measurement says that the powers of two occupy 0% of the positive integers.



By the way, what is your definition of quantifiable? I've never heard that word used, so I'm curious.

This topic is going in a very very weird direction 0.99999... = 1 and will probably end up in was there a second shooter on the grassy knoll but you should make the program so that you tell it how many decimal places to go. If you dont limit it it will never end creating an infinite loop and making your computer go crazy. oh and I found this "jborwein has the record for calculating pi (200 Billion decimal places!)" If your trying to calculate pi i think its a waste of time.

So, as I was thinking more about this thread, I realized something. As squeaker pointed out, a rational number always repeats. (If you consider a terminating decimal representation as repeating zeros. And I do.) Therefore, all you have to do is create a program that will calculate the decimal until it finds the point where the decimal representation starts to repeat, and stop calcuating there.
I attached the .txt file instead of posting all of the code from what I came up with.
The only problem I have with it is the output. I have it set up to place a bar over a repeating decimal, but if the decimal representation is too long to fit on one line of the console it looks terrible. To fix this will take some reworking of the output algorithm, but before I start, I have to figure out how I want to add in waiting for a keypress when the screen is full, which brings me to this:

you could probibly go to the tenth digit and you would be done!!

Not so. You'd be surprised at what kind of crazy repeating patterns I found just playing around with whatever numbers I put into the program. Consider 180/104297. The decimal representation contains a repeating pattern of more that 104,000 digits!
In fact, for every sequence of numbers of any arbitrarily large length, there are two integers, a and b, such that a/b = that sequence of numbers, and two integers, c and d, such that c/d = that sequence of numbers repeating itself infinitely! If that bucket of truth doesn't make your head spin the first time you read it, you weren't paying attention.

Originally Posted by Rashakil Fol

In order to talk about probability, you need some exact way of measuring probability. For example, if you take an infinite sequence of intervals [1,1], [1,2], [1,3], [1,4], ... and for each interval calculate the proportion of even numbers, you'll get a sequence that looks something like 0, 1/2, 1/3, 1/2, 2/5, 1/2, 3/7, 1/2, ..., which converges on 1/2. This would be one way of measuring probability when picking positive integers that gives intuitive results. For example, this form of measurement says that the powers of two occupy 0% of the positive integers.

Ha...just to muddle the issue further, you might be interested to know that the cardinality of the set of even integers and the cardinality of the set of powers of two are exactly the same and equal to the cardinality of the entire set of integers. So, while it may be true that 50% of the integers are even and roughly 0% of the integers are powers of two, it's also true that for every integer, there is an even integer and a power of two.