Is pi truely random?

Started by
64 comments, last by Hans 23 years, 11 months ago
I don''t think that the monkey will play all melodies eventually, some melodies requires the use of the pedals and since the monkey only uses its hands that would be impossible.

Thomas - www.moelhave.dk
Advertisement
If the probability that something happens in one time unit is >0 and the probability doesn''t change during the time passes it will happen if you wait long enough - you know this is true if you look at my previous post and the mathematical definition of probability.

Visit our homepage: www.rarebyte.de.st

GA
Visit our homepage: www.rarebyte.de.stGA
quote:Original post by Anonymous Poster
Getting back to compression...
What if you compressed the index using the same technique, and then compressed that index again for n times. Simple really.

Ok, go back and re-read my previous post on the compression of a 1024x768x8bpp bitmap. The average index number for such a "compression" would be around 2^6291456, and it''s a poisson distribution, so that the index could be *either* higher or lower than this number. If it''s higher by even 1, we need an extra bit of data to hold the index. In order for there to be even a single bit of compression the index would have to be at 2^6291455 - 1 or lower. Which is a difference of about 2^6291455. Remeber that the poisson distribution had an standard deviation of 2^3145728. Which means that the chances of compressing by even a single bit has a deviation of 2^3145727 SDs. In comparison the probability of an event outside of 1 SDs is about 37%. The probability of an event ousside of 2 SDs is about 5%. The probability of something outside of 6 SDs is usually considered statistcally insignificant. You see where this is going? The probability of an event outside of 2^3145727 SDs is so close to 0 that you might as well not even consider it. So If you tried to "compress" like this, you''ve got a 50-50 chance of actually increasing the size of the data, about a 50-50 chance of keeping the data the same size, and an essentially 0 chance of compressing the data by as little as one bit. Even if you tried to iterate over the index, you''d almost be assured that the "compression" would fail.

Not to mention the attempt is still intractable.
This monkey will NOT play every piece of music ever...

Assuming the monkey will live forever, and using both pedals and hands, his/her/it''s actions are not random... a monkey is a being with an intellect and other qualities of logic and such... it will make decisions based on what it will deem best... learning from his experience he will continue to make sounds that please him most... further more embedding his tastes in music... and most likely will end up playing a few keys over and over again until he became displeased with that set and made a new set... it can be assumed that the monkey will only play short sets or add to his existing set... either way, he will never accomplish all of the music ever created... I doubt he will ever correctly replicate ONE piece of music properly.

On the otherhand....

A computer that generates a randome tone WILL play every piece of music ever existed... assuming the following.

1. The random numbers generated are theoretically truly random, which is impossible for a computer to do
2. The computer exists infinitely
3. That damned monkey stops playing the piano.


40

www.databyss.com
www.omlettesoft.com

"Don''t meddle in the affairs of wizards, for they are subtle and quick to anger."
-40
nes8bit: I use 256 degrees instead of 360 degress. you should try it. there are many benefits in 256. especially when programming games. I mean then YOU, ''8bit'' would be able to store the angle in your 8-bit registers LOL.

With a binary number of degrees (2^n) - you get an automatic wrap around with 2^8 (256), just store it in a BYTE. otherwise just AND the value with (2^n)-1. I can''t see no real point in using 360 degrees apart from the fact that you can get 1/3rd of a revolution and 1/5th revolution.

Thats my (int) 2.7182818284653 pence [which is infact around 3.3 cents ].

/Memir
Flash Pool - Pool/Billiards game for Facebook (developed by Memir).
256 is not very accurate. I''d use 2048 and then angle&2047.

Correct me if i''m wrong, but I''ve heard that the processors these days calculate sin & cos so fast that you shouldn''t use arrays at all! Just use the orginal sin & cos functions.

-Hans

This topic is closed to new replies.

Advertisement