Units: Add Scaling and Scientific Notation

[jhwgh1968]

• [x] Everything I'm contributing is my own work, used with permission (and attributed as necessary), or is very clearly fair use
• [x] I agree to put my contribution into the Public Domain (or CC-0, if that doesn't apply where you are)

---

One of your TODOs.

I also took the liberty of trying to capture something even more important: numerical intuition. It's a bit brief, and really ought to be its own section, but at least this should give a good start.

[VegaDeftwing]

I had the briefest mention of scientific notation in /Math/algebra.md but you've done a much better job here. Thank you! I'd still like to do the rest of the TODO you cut EDIT: ope, just saw you left it in, just it got moved down, diffs are weird

by talking about some of the base units and how they form other units as well as mentioning some of the not-unit units like moles (which is effectively just a big number) and the "These are common but weird in name" like light-years being distance, not time - that sort of thing.

I was also considering adding something about reading graphs here, specifically Bode plots since the logarithmic nature of them universally trips people up.

I'm not asking you to do these things (by all means go for it if you want) I just want to be sure that if TODOs are removed they've been satisfied in full

[jhwgh1968]

I left the TODO in, because several of the topics seemed tangled together, and I didn't feel like I could remove it entirely without deleting more of the yarn ball than you intended.

I also thought about putting this stuff under Algebra, but the TODO was here. I imagined you would split/move it later, based on your previous commentary.

"Not units like moles" confused me, and felt like a mess. Because the mole was "broken" only very recently, compared to its original chemistry definition (which was much more useful to laboratories). Ditto for the even more fractured Dalton, which when I last looked (and has probably changed, because I can't find the article) was causing the Chemistry Union to hold up the SI definition vote.

Let me see if I can at least put in logarithms and graphs over the next couple days. If you don't hear from me in a week, go ahead and merge.

[VegaDeftwing]

By not-unit I meant that it's effectively just a symbol that stands in for a number, like π or e do.

Yeah, I think calling this section units in the first place may be half the problem, but I'm not sure what else to call it? There's definitely some issues with overlap between all of the chapters which makes it really hard to figure out what should be covered where. I'm doing my best to make it so the flow of information is being done such that, in theory, someone could read chapter by chapter in order without something in one chapter depending on something in a future chapter. That makes covering things like this hard, because it's hard to show why you should care about bode plots before something that uses them has been introduced, meanwhile it's hard to introduce those things without having bode plots and scientific notation and what not. There's been so many chicken and egg problems it's actually been a bit demotivating. It might not be a sensible thing to strive for in the first place anyway? What do you think?

Complicating things further, I definitely want to be sure OpGuides always has a "why should I care" on everything where someone might feel the need to ask. Similarly I want to avoid "textbook problems" where simple problems that are easy to do by hand with an incredible amount of idealizations are taught instead of just teaching how to use the software and tools that can actually solve the problem. So, here this might mean if we show a logarithmic plot we should show it in application, maybe that means showing reading a curve from a transistor datasheet or having an embedded video of a vocal sample running though an FFT plotted logarithmically and linearly, and talking about the pro/cons of each in the application. ╮(─▽─)╭

When I write, I really try to think to myself "When I learned this in school, what parts were left out, how and when could I ever actually use this, and how different is this from when people need to do this for 'real' engineering?", then, I work backwards. I try to write OpGuides from the perspective that you want to actually do something and that you're not learning just for the sake of learning. The math chapters are probably the hardest for this though, as I still want to avoid references to future chapters but keep them grounded like this. The way you've shown examples with real units here is doing a really good job of that honestly. The only way it could really be made more like what I mean is to set up more context for numbers, like saying "your laptop uses 15watts from normally, and you know you have a USB keyboard that draws 80mA at 5V, so what is the draw with the flash drive inserted?" or "You have 1TB harddrive and are taking a 10Mb picture once a minute, how long can you run your timelapse?" making sure the example isn't like "Jenny has 48 apples" - that is it should actually mean something to someone reading OpGuides

If you think something should go elsewhere, don't be afraid to just go for it. You're right that if I ever want to I can move it, but if you think it makes more sense in one place than the other, I trust your judgement. Also, as usual, while everything I said above is the goal, I don't expect to hit that goal right away. For how many pages are effectively stubs right now, pretty much anything goes. We can only look for the right pen and paper for so long before we actually have to sit down and write. Part of the power of the medium here is that we can go back and make improvements later. So write first, refine later is sort of the motto of OpGuides.

[jhwgh1968]

I'm doing my best to make it so the flow of information is being done such that, in theory, someone could read chapter by chapter in order without something in one chapter depending on something in a future chapter. [...] It might not be a sensible thing to strive for in the first place anyway? What do you think?

I think it's a good thing to strive for, but I think with a topic this big (even just the math that would help you for your other material), there will have to be at least some cross-referencing.

Complicating things further, I definitely want to be sure OpGuides always has a "why should I care" on everything where someone might feel the need to ask. Similarly I want to avoid "textbook problems" where simple problems that are easy to do by hand with an incredible amount of idealizations are taught instead of just teaching how to use the software and tools that can actually solve the problem.

I don't think I could completely reorganize it (and certainly not in this PR), but I do think having "units" turn into a "thought primer" page would be a good idea. Because I am motivated by a "why should you care" that is not exactly in your page, but dovetails with some of this section: the reader needs to learn to think intuitively about math problems rather than just seeing a bunch of numbers without any meaning.

As an amateur EE who has worked with a lot of Pros, the cornerstone of any endeavor is the skill of Design by Specification/Calculation. And that requires you intuitively grasp your problem -- the thing I think a lot of people who say "I'm no good with math" are missing (as noted in the book I referenced at the bottom).

That is the skill I'm trying to sneak into a discussion about units, i.e. ways to connect numbers on a page to real world things. I think it fits, but not well. The converse -- a page titled "really understanding problems", or something like that -- would make sense to have a units discussion in it.

So, here this might mean if we show a logarithmic plot we should show it in application, maybe that means showing reading a curve from a transistor datasheet or having an embedded video of a vocal sample running though an FFT plotted logarithmically and linearly, and talking about the pro/cons of each in the application. ╮(─▽─)╭

I thought about that, but decided that EE stuff would (ironically) require too much cross referencing and knowledge of values actually in a datasheet. :smile:

Instead, I went with COVID cases as an example of a real-life process that prefers exponential growth, and therefore should be analyzed that way.

When I write, I really try to think to myself "When I learned this in school, what parts were left out, how and when could I ever actually use this, and how different is this from when people need to do this for 'real' engineering?", then, I work backwards.

I hope I have satisfied that goal. I didn't really absorb the stuff I write about until college, because it was taught in a very fragmented way across a bunch of separate math and science classes in high school. If I had my way, I'd put "how to think mathematically" into every high school curriculum... and your page is just the next best thing.

The only way it could really be made more like what I mean is to set up more context for numbers, like saying "your laptop uses 15watts from normally, and you know you have a USB keyboard that draws 80mA at 5V, so what is the draw with the flash drive inserted?"

That's a good idea. I'll see if I can add that.

If you think something should go elsewhere, don't be afraid to just go for it. You're right that if I ever want to I can move it, but if you think it makes more sense in one place than the other, I trust your judgement.

As noted earlier, I think this makes the "least worst sense" where it is, and a better idea is to refactor the structure a bit more. So I'll stick with where it is for now.

[jhwgh1968]

Okay, that should do it @VegaDeftwing! I think this is ready to merge now.