things you wish you learned earlier

[koitsu]

I thought dB was logarithmic, which I always thought meant 2dB = 2x louder than 1dB, 3dB = 2x louder than 2dB, etc...

[Drag]

My experience with assembly programming has taught me:
1) Comment the FUCK out of your code (which has carried over into my C/C++ code)
2) There are only 3 real data types: numbers, arrays, and pointers. If one of those three things is confusing to you, you need to stop and sort it out in your head before you write any more code.
3) Everything boils down to being a collection of those three data types.

Hopefully, this will help someone.


Also I couldn't help but notice the C++ rants, so here's mine:

I'm writing a library in C++, and for libraries, I have a strict belief that a user of the library should never need to look at the source to be able to use it. Therefore, right in the header file, there's extensive explanation as to what each function does, and what each function expects out of you. I plan on writing proper documentation later on (it'd basically amount to copying my explanations out of the header files and arranging them more neatly), but it helps to be able to explain what each function does right as I'm coding it. Plus, I'm a dummy and I have a bad tendency to forget things if I don't touch them for a while, so I actually do need to comment everything and have paragraphs in my code explaining my reasoning behind what I'm doing. Even better is when I have one chunk of code, and then I think of a more optimal way to do it, and then my more optimal way doesn't work or breaks something else. I'll change it back and leave a nice comment stating why my optimization didn't work, so in the future I won't try it again.

And my code is full of this stuff, just a running commentary and explanations. This is probably the stark opposite of what most other coders do, which is even more of a reason for why I do it. Usually for research (for example, I've been researching Yamaha FM synthesis), I have to look through other people's code, and what it taught me is that I hate programmers, I hate people who try too hard to be clever, and I hate looking at code.

Did you catch all of that? I'm a programmer who hates other programmers, hates overcleverness, hates code, has to constantly remind himself why he coded something a particular way, and has to constantly explain absolutely everything, and my code definitely reflects all of this.

[Drag]

I thought dB was logarithmic, which I always thought meant 2dB = 2x louder than 1dB, 3dB = 2x louder than 2dB, etc...

dB is weird. It's a relative measure of amplitude or voltage or whatever. "0dB" can mean anything, but it usually refers to a lack of attenuation, or a lack of any other change. If you want to plug in a dB value and know how much it'll affect the signal, use: 10 ^ (dB / 20). So for example, -6dB = 10 ^ (-6/20) = 0.50119, which is not quite half but close enough to round to half if you're talking about a PSG's volume control. Therefore, if you know your PSG's volume control attenuates in 2dB steps, it means that every 3rd setting halves the volume.

So yes, it's logarithmic, and you were pretty close, just take your understanding and multiply it by 6.

[lidnariq]

I thought dB was logarithmic, which I always thought meant 2dB = 2x louder than 1dB, 3dB = 2x louder than 2dB, etc...

You're almost right, but the common use of deciBels, as well as muddying voltage (or code) vs power, confuses things.

A Bel is a factor of 10, so a deciBel would be 10^(1/10). Except when it's 10^(1/20). Ugh.

[thefox]

I plan on writing proper documentation later on (it'd basically amount to copying my explanations out of the header files and arranging them more neatly), but it helps to be able to explain what each function does right as I'm coding it.

Doxygen.

[JRoatch]

I wish I knew that calculus was about derivatives and integration, and not just a word for "fancy math".

[Jarhmander]

I thought dB was logarithmic, which I always thought meant 2dB = 2x louder than 1dB, 3dB = 2x louder than 2dB, etc...

You're almost right, but the common use of deciBels, as well as muddying voltage (or code) vs power, confuses things.

A Bel is a factor of 10, so a deciBel would be 10^(1/10). Except when it's 10^(1/20). Ugh.

The unit "deciBel" refers to a ratio of two power (in Watts), resulting in a "unitless" number (a bit like radians). When powers are used, the standard definition of the dB is used: 10*log10(P1/P2). That will give the (power) gain of an amplifier, for example.

But many times, you don't know directly the power of your signals, instead you know the amplitude. Well, in many, if not all the cases, power is related to the square of the magnitude (be it volts, pascals, etc). That's very simple to show with electricity:

P = V * I (Power in terms of current and voltage)
V = R * I (Ohm's law)
P = V² / R (Rearanging the above equations)

Suppose you want to measure the gain of your amplifier across a load R, then in the dB conversion, the Rs cancel out, giving you: dB_gain = 10*log10(Vout²/Vin²), which is 10*log10( (Vout/Vin)² ), which is 20*log10(Vout/Vin), when knowing the appropriate logarithmic identity.

When you work with digital signals however, there's no real units associated with them, however we can just assume that those signals are some amplitude (with a DAC they would be converted to real, physical volts) so the 20*log10(A1/A2) conversion is still used.

TL;DR: when dealing with powers, use 10*log10(P1/P2), when dealing with amplitudes, use 20*log10(A1/A2).

Also, I wish I was more confident when I was younger, I was afraid of lots of things for no good reason.

Edit: Also, koitsu is right if we adjust the numbers used: 10dB = 10x the power of 0dB, 20 dB = 10x the power of 10dB, 30dB = 10x the power of 20dB ...

[zzo38]

I wish I knew that calculus was about derivatives and integration, and not just a word for "fancy math".

And the word "calculus" is used in other circumstances too, such as "sequent calculus".

[tepples]

Not to mention lambda calculus, which formalizes what a function pointer represents.

[Bregalad]

2) There are only 3 real data types: numbers, arrays, and pointers. If one of those three things is confusing to you, you need to stop and sort it out in your head before you write any more code.

Not quite, arrays are just several numbers in a row, and pointers are numbers that represent an address. So overall, there is only 1 real data type : numbers.

[Drag]

2) There are only 3 real data types: numbers, arrays, and pointers. If one of those three things is confusing to you, you need to stop and sort it out in your head before you write any more code.

Not quite, arrays are just several numbers in a row, and pointers are numbers that represent an address. So overall, there is only 1 real data type : numbers.

Do me a huge favor and don't write code.

Nah, kidding.

If most CPUs didn't contain opcodes or anything specialized for accessing arrays or using pointers, then I'd agree with you, but the following is why I don't:

Arrays are indeed just a bunch of numbers in a row, but you access them differently from plain numbers: You have a known starting point, and you add an offset to it. Most CPU architectures (including the 6502) have functionality specifically designed to access members of an array, which is important to point out because CPUs typically don't have functionality specifically designed to access linked lists for example; you do that in software.

Pointers are a huge thing that confuses almost everyone I've talked to, unless they started with C or have done any kind of assembly programming or even any kind of (semi-advanced) rom hacking. A pointer is a memory address, stored like a number. It tells you where something is, in memory, but it's stored like a number, so you can manipulate it like one. Again, most CPU architectures contain functionality specifically designed to treat a number like a pointer, which is different from treating a constant like a pointer.

Finally, any kind of data structure you can think of is a combination of these three things.

[tepples]

CPUs typically don't have functionality specifically designed to access linked lists for example; you do that in software.

Unless, of course, you're implementing Lisp on a 36-bit machine with 15-bit addresses. But this is atypical.

[Bavi_H]

I thought dB was logarithmic, which I always thought meant 2dB = 2x louder than 1dB, 3dB = 2x louder than 2dB, etc...

You're thinking of base-2 logarithmic. In brief,

• Bels are base-10 logarithmic. 1 bel is 10 times the power of 0 bels.
• 1 bel is 10 decibels.
• Wikipedia says "in most applications power is proportional to the square of amplitude."

Putting that all together, 6 decibels is close to 2 times the amplitude of 0 decibels.

[zzo38]

My experience with assembly programming has taught me:
1) Comment the FUCK out of your code (which has carried over into my C/C++ code)

I do tend to write more comments in assembly language program than in a C program.

2) There are only 3 real data types: numbers, arrays, and pointers. If one of those three things is confusing to you, you need to stop and sort it out in your head before you write any more code.
3) Everything boils down to being a collection of those three data types.

Yes, I suppose that certainly works. I do find these kind of thing to be useful, although of course some people don't like it.

I'm writing a library in C++, and for libraries, I have a strict belief that a user of the library should never need to look at the source to be able to use it. Therefore, right in the header file, there's extensive explanation as to what each function does, and what each function expects out of you.

I agree, although I am using C instead of C++. However, I might not necessarily put full documentation in the header file; it might be a separate file (although there will be some comments in the header file with short explanations). If the library is a SQLite extension library, then there won't be any header file.

You don't have to read my programs if you don't like it.

[Bregalad]

Do me a huge favor and don't write code.

To be honest I'd like to. I now think the writing code is the most boring part of computer science - designing algorithms is the interesting and fun part of it.
Unfortunately since I can't enough to have dozen of slaves writing code that I'd like them to write for me, I have to write code myself.