If xx=x, then xx-x=0. Therefore x*(x-1)=0. So either x=0, or x-1=0, i.e. x=1.
1/9 doesn’t equal 0 or 1, so (1/9)*(1/9) doesn’t equal (1/9).
Regarding the decimal expansion of 1/81: it doesn’t end with “0987654321”. (It doesn’t end at all, in fact.) If your calculator is telling you that it does end with those digits, then yes something is wrong there; possibly an example of floating-point error.
Finally, 0.99999…=1. (Although some people refuse to believe that fact; there have been debates about this before on this board. Nevertheless, 0.99999…=1.)
Calculators notwithstanding, the math behind the phenomena you’re getting are:
(1/9) × * (1/9) = 1/81 = 0.01234567890123456789…
and
0.99999… = 1
This last little factoid is a classical mathematical paradox that has been discussed several times on this board, but I think we need to tackle the simpler problems first.
Why would you think that 0.111… × 0.111… = 0.111…? Either you need to step back and take a good, long look at what you’re doing, or you’ve been badly misinformed about multiplication. Do you think you can just multiply the digits? Do you think that 23 × 23 = 49?
The reason you’re getting the reversed digits, I’m willing to bet, is that you’re only inputting a few digits. For instance, if you use 0.111 instead of 1/9, you get:
0.111 × 0.111 = 0.012321
The more digits you put in, the more accurate your result will be. But even if you use 0.1111111111111111111111111111111, it’s eventually going to stop being right at some point.
Sorry about that Math Geek!
I felt it was already implied that 1/81 repeated like that.
I was saying that 1/9 * 1/9 ended with that string backwards and that “(1/9)/9” ended differently as well.
I believe it ends 0.12345679012222222222222222…
All three end differently! It still seems beyond common sense ( a stroke of magic by an idealistic programmer maybe ) that one would pull out all of the numbers from a specific base out of:
1/b squared !!
Let people have the truth! chuckle
These designations seem arbitrary to me; particularly in the case of (1/9) * (1/9).
Why would you think that 1/9 squared should be 1/9 ?
Only multiplying by 1 would give you the original number, in this case:
.111… * 1 = .111…
.111… * .111… would be a little more than a tenth of that.
Namely, it can be thought of as the sum of:
.1 * .111… (. 01111…)
.01 * .111… (.00111…)
+.001 * .111… (.000111…)
and so on, so your total is (.111… * .111…) = .01234…
As to the 9 * (1/9), question, the calculator does have to round off numbers when it presents them to you - otherwise you’d never be able to use the calculator again after entering 1/9 since it would coutinue to spew out 1’s until the batteries wore out.
Now, the calculator can only show you the representation of 1/9 as .111…, but the function (1/9) is being stored in the memory. When you input (1/9) * 9, it isn’t coming up with “.111… * 9”, it’s coming up with “(1/9) * 9” (even though your display might say differently, the 1/9 is still in memory as being 1/9, not .111), and the result is 1.
I’m running 10000 points of precision on a floating point calculator with all of the different inputs I receive for something which (if anything) should at least be a consistent wash in regards to this mathematical philosophy.
Am I really inputing 1/81 when I’m doing this?
Umm… I don’t think so…
I’m inputing:
1/9 which equals 0.111111111111
(implied in the ‘backround’)
and multiplying it by itself … this isn’t addition here!
Gotcha. I’m still not swallowing the part where the 8 magically sneaks in there on the last sequence; when I specifically type 1/9 squared as opposed to other inputs.
Is it considered a mathematical ‘law’ that the end of
(1/(base-1))
spews out all of the digits in that base as a countdown until termination?
Since there are presumably mathematics enthusiasts peeking in here…
Are there calculators designed to use multiple decimal points as abstraction layer designations (‘multiple dimensions’); like ip addresses are seen? It would make working with algorythms much easier… I run into this quite a bit and have always wondered if someone has created such a beast yet. It would save lots of time run repeating systems of operators, rather than a single operator; and then only working with the repeating output.
Does that make sense?
Do calculators like that exist?
I think you have an inflated idea of what the periods are for in an IP address. They’re just placeholders put there for readability, not much different from the commas in the number “1,000,000”.
An IP address is just a big number written in a funny way; for example, the address 128.0.0.1 is just a peculiar way of writing the number (in hex) 80000001. It’s just that 80000001 looks big and scary, so we break it up into four chunks (and then convert each of the chunks into decimal). Just like the decimal number 1000000 is hard to read, so we break it up into chunks and write it 1,000,000 instread.
You’re getting pretty philosophical about the rounding done on a calculator, methinks, Justhink. If you’re squaring a number, you should only expect as many digits of precion out of the result as you put in. For instance, using 0.111 for 1/9 is only three digits of precision. So when I square it and get 0.012321, really I should only look at the first three digits, that is, 0.0123. Not only is it not surprising that the digits after that point are wrong, it’s expected. Now, if we do like you did, “1/9 which equals 0.111111111111”, that’s only 12 digits of precision, and we should expect that the result will only be good out to 12 digits as well.
Now, if you really have 10,000 digits of precision, like you mention, then you should expect the answer to be good to about 10,000 digits. But I’ve never seen a calculator like that, and even then, you’d expect the result to break down after 10,000 digits.
The calculator (program) I’m currently using is only limited by storage capability in a word processing program. I think it’s slightly over 1,000,000 digits of precision in Windows.
As for a calculator which uses only one decimal point for division (or one decimal point period!!); I have found many instances of requiring to tack on finite and infinite numbers on either ‘end’ of the spectrum. Doing this by hand is a pain in the @$$!
I find myself requiring a decimal like 1/9 to act as a number spawning out from the ‘center’; while tacking on a decimal output like 1/3 on one end, and maybe a finite on another; or to create multiple layers of simultaneous processing by creating ‘geometric’ patterns (in the sense of dimension abstraction #'s); to allow for the live observation of emergence in division coding.
It doesn’t matter how many digits of precision you’ve got, you’re going to get a rounding error.
It’s very easy to see that 1/9 squared is identical to 1/81:
(1/9)(1/9) = (11)/(9*9) = 1/81.
This number has a repeating, non-terminating decimal expression. When your calculator divides out 1/81, it clearly shows you what this repeating expression is. And apparently, on the other hand, when you are multiplying 1/9 times 1/9, first the calculator rounds off each 1/9 to .111111…111 (finitely many ones), then does the multiplication, which produces the bullshit 987654321 at the end of the number. In other words:
(1/9)*(1/9) = 0.01234567901234567901234567901234579… (repeating forever), while
since you didn’t really multiply 1/9 times 1/9 here, you multiplied two numbers that are each close to 1/9, giving you the rounding error, accounting for the difference between this and (1/9)*(1/9). And it doesn’t matter how many digits you take this out to: .111111111…1 is merely a finite number of digits, while 1/9 = .1111111… consists of an infinite number of digits–quite a difference, isn’t it?