Step 3More theory on musical numbers
You might want to skip this step for now unless you really want or need to know.
The number being explored (zero point one two three four five six ...) is normal.
Normality is actually NOT optimal for musical numbers, and in fact by avoiding
normality, a lot of white noise can be excluded. And it's convenient to put the
white noise beside another trash bin which I call the set of impossible sounds.
The impossible sounds are playable, but have been known to damage certain
kinds of speakers. I think I have a picture, which I will post if I find it.
WHOA! Damaging speakers? If you have seen the calcul8.txt file in a sound
editor, the off-centerness has something to do with it. ...9999999999... is a Very-
Bad number because it could heat up the speaker and push the cone out!
And you might not notice, because it might just be quiet and start smoking.
Don't hook up any of my Pandora's Boxes to your really expensive audio
gear. Transistor radio speakers like the ones in my Magnet Phone instructable
won't mind the 9's as much, especially since they are used with cheap amps.
Since I'm still talking about using human numbers which can be seen in The Number,
I'll mention this other fact about The Number:
It is not only normal, but it has an average digit of 4.5.
4.5 is the middle of the numbers 01234.56789 .
The Number (I'm calling it that because sooner or later most of what I write about
it gets removed from search engines, and since I've noticed that, it doesn't hurt
to be paranoid, whatever the reason is for why that happens.)
The Number (this is what the math whizzes will object to) offers not much in the
way of advantages as a data source, except that it doesn't need the enormous
amount of memory that would be able to store it.
The Number seems to require even bigger numbers to access all of the data
in it, but only at first, and then it seems to require ones of similar or slightly
smaller size. In other words:
THE MATH FOR USING THE NUMBER AS DIRECTED
APPEARS TO WASTE IMAGINARY MEMORY.
As long as the memory is imaginary, maybe we don't have to care.
Wait! What's imaginary memory? An example is the multiplication table.
I'm not just talking about what was memorized in elementary school,
but the infinite plane of all numbers multiplied together. A computer
does not have to store that anywhere, nor could it, to retrieve the
answer to a multiplication.
Neither does The Number need to be stored anywhere.
Neither does it need a decimal point. Only whole-number math is
necessary to access it.
Now let's go back to throwing away the noise in The Number.
I'm going to work with this number as long as it takes to teach the theory.
MUSICAL NUMBERS SHOULD NOT BE NORMAL.
MUSICAL NUMBERS IN "THE NUMBER" SHOULD HAVE MORE 4's and 5's.
If you found, tried, played, looked at the "calcul8" number mentioned elsewhere,
you would have noticed that it has a lot of 4's and 5's, and is Not Normal, and
probably has an average digit of 4.5 unless it's been modified or corrupted.
I shouldn't do this just yet, but there is a smaller, more musical number with
all the music in it than The Number, which is much more likely when a long
number is pulled out of it, will have an average digit of 4.5, and will have
much less white noise. Imagine how many numbers are removed from The
Number (as if it were made by counting, which is unnecessary, just easy and slow)
and how many numbers don't have an average digit of 4.5. MOST DON'T!
I shouldn't go beyond The Number just yet because it's probably still blowing
your minds that this number is infinite, and contains all possible sounds near
the beginning of it. And that counting is the slow way but math is the fast way
to find and pull sound out of it.
How slow is counting to a musical number you recognize as a song?
The fastest computer couldn't have done it if it started at the beginning of time!
How fast is the math? Quite reasonable. Some multiple of the time it takes
to do a memory test. No musical number will ever be bigger than if you
filled your memory with ONES, as I think I explained earlier.
Unfortunately, the project this instructable is or will be about building is
going to start with counting because it's easy. But I hope it will not
disappoint. I will try to stretch it a little with some interesting circuit bending,
or alternative enumeration of the sound.
Enumeration: The order in which all these sounds are sorted.
There's a first sound, a second sound, a third sound...
and we can change WHO'S ON FIRST!
I may hear new things too. I expect to be surprised by any new alternative enumerations.
And we're still just watching Sesame Street and learning to count ... SOUNDS!
Still makeing... sorry for the delay... and that "my brain is about to explode" feeling.
(Nope, now it's done, now to "explain away" the big mess!)
| « Previous Step | Download PDFView All Steps | Next Step » |

















































I'm not just talking about what was memorized in elementary school,
but the infinite plane of all numbers multiplied together. A computer
does not have to store that anywhere, nor could it, to retrieve the
answer to a multiplication.[/quote]Actually, processor chips *do* store all the numbers in a table and look them up when they have to do multiplication. It also works backwards for division. It's faster than actually doing the maths the way humans do it.
This is how the infamous Pentium Bug happened - the chip designers thought they could remove, sorry, optimise further some of the values, and the result was that the look-ups were then wrong.
http://www.maa.org/mathland/mathland_5_12.html
See http://www.cs.earlham.edu/~dusko/cs63/fdiv.html and http://support.intel.com/support/processors/pentium/sb/CS-013007.htm (Last paragraph reads:
"The cause of the problem traces itself to a few missing entries in a lookup table used in the hardware implementation algorithm for the divide operation. Since this divide operation is used by the Divide, Remaindering, and certain Transcendental Instructions, an inaccuracy introduced in the operation manifests itself as an inaccuracy in the results generated by these instructions."
The reason this bug occurred was because someone thought they could further optimise the already fully optimised table by removing a few numbers that "weren't needed" but in fact were. This was to reduce the size of the look-up in the FPU.
In the era of the Pentiums, they used a faster variant of the ever-popular SRT algorithm, calculating two bits (radix-2) at a time instead of one. (Off-topic: Very recently, Intel bumped this again to using a radix-4 division algorithm in the Core 2 family, which almost halved the throughput latency of the FDIV and related operations.) A full LUT-based Pentium FPU would need a 280 lookup table, which is absolutely enormous, and unrealistic (you would need several quadrillion quadrillion bytes). By successively approximating the solution to the division until the error is too small to be represented by IEEE754 at any given bit depth (in this case, 80-bits), you can implement a full hardware FPU without having to have that enormous lookup table.
FPUs work much like we do when we go about solving a long division problem, a digit at a time (solving the recurrence relationship). After every step in the division, we calculate partial values by multiplication (CPUs use left- or right-shifts instead) and subtraction, and use the partial remainder values to complete the next digit(s). FPUs look up the next digit instead of calculating it directly to avoid the need for additional latency for this operation, much as we know that 5 will go into 15 evenly without having to go to a calculator. (Oddly enough, we happen know this because when we're kids, we are taught at least a base-10, 144-value LUT ("times table"/"multiplication table"), which happens to be really convenient when doing traditional math.)
The problem with the FPU was similarly pretty simple. The (IIRC) 1066-entry-long M*d LUT used to find the next quotient digit based on the last partial remainder (M) and the divisor (d) in the algorithm was five entries short. All of these entries contained 0, when they were meant to contain "+2". These entries were removed from the table after some engineer(s?) did some bad math while trying to prove these entries unreachable when in fact they were reachable, just very, very rarely (1 in 9 billion random operations). (Alternatively offered by some Intel-sponsored revisionist-historians was that these engineers simply "forgot to program the table with these values", however, this is exceedingly unlikely.)
So yes, it uses a LUT, but as a way of making the successive approximation algorithm faster, not to "look up the solution." You could leave the LUT out and still build an FPU, but it would be much more latent, which would sell fewer chips.