I discovered something profoundly usesless today: When you combine a square wave at amplitude 2x, pitch y with a sawtooth at amplitude x, pitch 2y, the result is a sawtooth at amplitude 2x, pitch y, when the two waves are in phase with each other.
square(2a,p) + saw(a,2p) = saw(2a,p)
I can prove it using the harmonic series, but first I should warn that I am not a good mathematician, and there may be errors here, and the above proposition may be false. Please let me know if you see any errors; children will starve if any flaws go unnoticed.
A square wave (http://en.wikipedia.org/wiki/Square_wave) contains every odd-integer harmonic n at amplitude a/n where a is the amplitude of the fundamental (the first harmonic). (Please pardon the infinitely recursive definition... the fundamental is at volume a.)
A sawtooth wave (http://en.wikipedia.org/wiki/Sawtooth_wave) contains every integer harmonic n at amplitude a/n where a is the amplitude of the fundamental.
Now, to sum the amplitudes of the harmonics of the 2 waves, we can express one wave's harmonics in terms of the other wave. Since the square wave in this proposition is lower in frequency and double the amplitude of the sawtooth, I will call its frequency the fundamental (first harmonic) for this example. (After all, it _is_ the fundamental if both are played together anyway, but that's irrelevant to this proof.)
Since the frequency of the sawtooth wave is double that of the square wave, its nth harmonic is the (2n)th harmonic of the square wave. Therefore, it will provide all the even-numbered harmonics. Since its amplitude is half that of the square wave, its fundamental (the 2nd harmonic of the square wave) will sound at 1/2 the amplitude of the square wave, its 2nd harmonic (the 4th harmonic of the quare wave) will sound at 1/2 _that_ amplitude, its 3rd harmonic (the 6th harmonic of the square wave) will sound at 1/3 its amplitude (1/6 that of the square wave), etc.
So, the square wave provides all odd-numbered harmonics n at amplitude 1/n, and the sawtooth provides all even-numbered harmonics _of our resulting wave_ at 1/n. Therefore, by combining a square wave and a sawtooth at twice the frequency and half the amplitude, we have all integer harmonics at volume 1/n, which is a sawtooth at the pitch and amplitude of the contributing square wave.
I guess there is one application to this: On a synthesizer, using a sawtooth oscillator combined with a square oscillator one octave lower at the same volume is useless. One octave lower because that's half the frequency, and the same volume because that's twice the ampltidue and frequency times amplitdue equals volume. So the moral of the story: Just use a saw!
Tuesday, September 13, 2011
Friday, November 12, 2010
Small World Technologies
I now have a side job working at Small World Technologies to make mobile apps.
Thursday, August 5, 2010
Wednesday, July 14, 2010
Windows Command Prompt Keeps Up with One Current Directory Per Drive
Or so it seems. This is copied from a console window on a machine running Windows Server 2003:
Oddly, using the /d flag is required to change directories across drives [reference].
C:\Documents and Settings\jyoung>cd E:\InetPub\web sitesVery strange. It seems that the command prompt keeps up with the “current directory” on a per-drive basis, so that when you cd to some drive that you’re not on, it changes the “current” directory for that drive rather than _the_ current directory. Then when you change drives, it remembers what drive you changed it to previously. I did not know that.
C:\Documents and Settings\jyoung>cd "E:\InetPub\web sites"
C:\Documents and Settings\jyoung>cd e:
E:\InetPub\web sites
C:\Documents and Settings\jyoung>e:
E:\InetPub\web sites>
Oddly, using the /d flag is required to change directories across drives [reference].
Labels:
Windows Command
Friday, June 25, 2010
Do your work, or throw an exception - example
The last post gave an illustration of a employee telling his manager if he cannot do his work as usual instead of requiring his manager to ask him if he will start doing what is expected of him every time she asks him to.
Below is a code example of this idea that I posted on StackOverflow:
Imagine using each of these. Using GoodEmployee means that client code can operate as normal. Wherever appropriate, _if_ appropriate, a try/catch _may_ be used to properly handle the exception, if that is even possible. The most appropriate try/catch may be in place already in a form something like this:
Meanwhile, client code of GoodEmployee may look like this:
Contrast this with proper usage of BadEmployee:
Not _so_ bad. But what if we call DoWork in lots of places? What if there are not 1 but many different methods like DoWork that have to be called? Worst of all, what if we want to have N layers of indirection that must exit when the employee cannot do his work? What if we apply this same pattern (return error codes instead of throwing an exception) to those methods? Then we have something like this:
YUCK!
I have worked on an application like this. Making any minor little changes to it is an absolute pain because it employs the above pattern throughout. Contrast that with otherwise comparable apps that throws exceptions and allows exceptions to be thrown--the latter group of apps not only have less code, cleaner code, and fewer bugs, they also have _more robust_ exception handling.
I hope these clearly examples show how exception-phobia and speculative catch blocks are destructive and literally multiply the amount of code you have to maintain, as well as hide and even introduce bugs.
Below is a code example of this idea that I posted on StackOverflow:
class GoodEmployee {
void DoWork() {
if (CarIsInTheShop)
throw new CantDoWorkException();
else
_DoWork();
}
}
class BadEmployee {
bool DoWork() {
if (CarIsInTheShop)
return false;
else
{
_DoWork();
return true;
}
}
}
Imagine using each of these. Using GoodEmployee means that client code can operate as normal. Wherever appropriate, _if_ appropriate, a try/catch _may_ be used to properly handle the exception, if that is even possible. The most appropriate try/catch may be in place already in a form something like this:
// main loop:
while(!timeToQuit) {
try {
REPL(); // read eval print loop, for example
}
catch (TransientException e) {
TellUserHeCantDoThatRightNow(e);
}
}
Meanwhile, client code of GoodEmployee may look like this:
myGoodEmployee.DoWork();
Contrast this with proper usage of BadEmployee:
if (!myBadEmployee.DoWork) {
return false;
}
...
return true;
Not _so_ bad. But what if we call DoWork in lots of places? What if there are not 1 but many different methods like DoWork that have to be called? Worst of all, what if we want to have N layers of indirection that must exit when the employee cannot do his work? What if we apply this same pattern (return error codes instead of throwing an exception) to those methods? Then we have something like this:
A() {
if (!B())
return false;
// do some other work;
return true;
}
B() {
if (!C())
return false;
// do some other work;
return true;
}
C() {
if (!myEmployee.DoWork1())
return false;
if (!myEmployee.DoWork2())
return false;
if (!myEmployee.DoWork3())
return false;
// do some other stuff
return true;
}
YUCK!
I have worked on an application like this. Making any minor little changes to it is an absolute pain because it employs the above pattern throughout. Contrast that with otherwise comparable apps that throws exceptions and allows exceptions to be thrown--the latter group of apps not only have less code, cleaner code, and fewer bugs, they also have _more robust_ exception handling.
I hope these clearly examples show how exception-phobia and speculative catch blocks are destructive and literally multiply the amount of code you have to maintain, as well as hide and even introduce bugs.
Labels:
exception handling
Subscribe to:
Posts (Atom)