I'm a chemical engineer and I now better understand calculus slightly better from this post. I did a whole lot of "okkayyy
...let's just stick to the process and wait for this whole thing to blow over"
I know what they were asking me to do but I never really fully understood everything.
I also studied chemical engineering, and throughout high school and university that was exactly it. Calculus was a kind of magic, and you just had to learn all the spells.
With this book I finally understood why the derivative of x^2 is 2x.
Read "a mathematicians lament", by Paul Lockhart. It was originally a short essay (25 pages you can find free online), but expanded into a book that I haven't read yet.
I read a short paper called "Lockheart's Lament", but I didn't realize he had expanded on it. I might have cried about that one. Thanks for the reccomendations!
There was a lovely computer science book for kids I can't remember the name of, and it was all about the evil jargon trying to prevent people from mastering the magical skills of programming and algorithms. I love these approaches. I grew up in an extremely non/anti-academic environment, and I learned to explain things in non-academic ways, and it's really helped me as an intro lecturer.
Jargon is the mind killer. Shorthands are for the people who have enough expertise to really feel the depths of that shorthand and use it to tickle the old familiar neurons they represent without needing to do the whole dance. It's easy to forget that to a newcomer, the symbol is just a symbol.
Jargon is the little-death that brings total confusion. I will face the jargon. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the jargon has gone there will be clarity. Only sense will remain.
The most annoying thing about learning networking and security are all the acronyms! Sometimes it feels like certification tests are testing acronym memorization more than real concepts.
In a way it makes sense because the industry loves its acronyms and you'll be using them.
On the other hand, I have the ability to search. I'm an IT professional, I will have a computer. Let me let the computer do the lookup. Its the old "you won't have a calculator with you all the time" argument that was dated when my teachers told it to me.
Absolutely! One of the difficulties that I have with my intro courses is working out when to introduce the vocabulary correctly, because it is important to be able to engage with the industry and the literature, but it adds a lot of noise to learning the underlying concepts and some assessments end up losing sight of the concept and go straight to recalling the vocab.
Knowing the terms can help you self-learn, but a textbook glossary could do the same thing.
Whenever people talk about evil jargons, or "anti-dummies" wording, the first thing that comes into my mind is lawspeak. You know, how fucking laws are worded, which are anything but obvious to people that only speak "peasant". It's worse than academic jargon because it's something that is likely to be used against you.
Yeah, I may be wrong but I think it usually comes down to a very specific kind of precision needed. It's not meant to be hostile, I think, but meant to provide a domain-specific explanation clearly to those who need to interpret it in a specific way. In law, specific jargon infers very specific behaviour, so it's meant to be precise in its own way (not a law major, can't say for sure), but it can seem completely meaningless if you aren't prepped for it.
Same thing in other fields. I had a professor who was very pedantic about {braces} vs [brackets] vs (parentheses), and it seemed totally unnecessary to be so corrective in discussions, but when explaining where things went wrong with a student's work it was vital to be able to quickly differentiate them in their work so they could review the right areas or understand things faster during a lecture later down the line.
But that noise takes longer to teach through, so if it is important, it needs it's own time to learn, and it will make it inaccessible to anyone who didn't get that time to learn and digest it.
The author of these paragraphs summarizes it very nicely. It takes a lot of talent to break things down like this, I wish more math textbooks were written this way.
I often find that I find mathematical concepts much easier to understand if they're presented as Python code rather than math notation. Someone should write a book like that.
Algebraic notation breaks just about every rule programmers are taught about keeping their code human readable. For example:
Variable and function names should be descriptive
Don't cram everything into one line
Break up large statements
Consistency is key
Don't be fancy for fancy's sake, don't over-optimize (this is for learning, remember?)
Add in-line comments for lines that aren't easily grasped
Be explicit where possible (it's a convention to omit the multiplication operator when multiplying variables because variables are only one letter anyway...)
And then we force kids to cram the whole stdlib (or rather its local bastardization) into their heads or at best give them intentionally bad (uncommented) documentation during exams while wondering why so many just don't seem to get it, even resent it.
I feel like this isn't quite fair to math, most of these can apply to school math (when taught in a very bad way) but not even always there imo.
Its true that math notation generally doesn't give things very descriptive names, but most of the time, depending on where you are learning and what you are learning, symbols for variables/functions do hint at what the object is supposed to be
E.g.: When working in linear algebra capital letters (especially A, B, C, D as well as M) are generally Matrices, v, w, u are usually vectors and V, W are vector spaces. Along with conventions that are largely independent of the specific math you are doing, like n, m, k usually being integers, i or j being indices, f and g being functions and x, y, z being unknowns.
Also math statements should be given comments too. But usually this function is served by the text around the equations or the commentary given along side them, so its not a direct part of the symbolic writing itself (unlike comments being a direct part of source code). And when a long symbolic expression isn't broken up or given much commentary that is usually an implicit sign that it should be easy/quick for the reader to understand/derive based on previously learned material.
Finally there's also the Problem with having to manipulate the symbols. In Code you just write it and then the computer has to deal with it (and it doesn't care how verbose you made a variable name). But in math you are generally expected to work with your symbolic expressions and manipulate them. And its very cumbersome to keep having to rewrite multi-letter names every time you manipulate an expression. Additionally math is still generally worked on in paper first, and then transferred into a digital/printed format second, so you can't just copy + paste or rely on auto completion to move long variable names around, like you might when coding.
Functional programming is much more math oriented and I think works well here, as it likes to violate a lot of these rules as a rule. I think it's what makes it so challenging and so obvious for different folks.
You can't except learning the science of abstraction by making it concrete. Exampled are not more than examples and if one field required abstract theory, it is indeed the mathematics.
That's an interesting notion.
For you, is it when it's presented like: sum = sum([1,2,3]), or when it's dropping in and explaining how the sum function is implemented?
I think there's definitely something there in either case, but teaching math through "how you would implement it in code" seems really interesting. You could start really basic, and then as you get to more complicated math, you keep using the tools you built before. When you get to those "big idea" moments, you could go back to your old functions and modify them to work in the new use case while still supporting the old. Like showing how multiplication() needs to change to support complex numbers without making anything else different.
but teaching math through “how you would implement it in code” seems really interesting.
This is near exactly how I handled learning advanced mathematics back in the late 80s and early 90s. This method takes the abstract and makes it practical, which is what many people really need in order to effectively learn.
I know this is just a simple example but sum() doesn't teach you about the concept of sums. It would have to be something like:
def sum_up(my_list):
result = 0
for item in my_list:
result = result + item
return result
Then you could run that through a debugger and see how the variables change at every step. That way you can develop an understanding of what's going on there.
This was so much me with the concept of generalized Cartesian product. All the class was very confused with that topic, until a bright classmate pointed-out a relationship of that concept with Python list and it started to do so much sense.
Minor nitpick: the "d" is an operator, not a variable. So it's "dx", not "dx"... But there are so many textbooks that don't get this right, that I'm aware that I'm charging windmills here.
My intro to calculus came in the form of a battered copy of a 1979 historical calculus textbook by W.M. Priestley, it was significantly easier to understand than any of the usual intro to calculus textbooks that I've seen.
Calculus was never an issue for me. I could do double-integral calculus in my head clear into my forties. I’ve just gotten rusty since then, likely with a spot of practice I could pull off that party trick again.
No, the only part of math that ever struck fear into my heart was trigonometry. Sin, cos, tan, that kind of stuff. For some reason I have never been able to grok, on a fundamental level, the basics of trig. I understand things on a high/intellectual level, just not on an instinctual level.
Sure. They relate different properties of triangles or periodic phenomena.
But can you explain what a "sine" operation is actually doing? Algebra and calculus can pretty much all be explained in terms of basic operations like addition, subtraction, multiplication, and division. But I'm in the same boat as @rekabis@lemmy.ca - trig operations feel like a black box where one number goes in and a different number comes out. I am comfortable using them and understand their patterns, but don't really get them.
I mean, the idea is simple enough to understand. The actual execution is what fucks idiots like me, especially when the exam is full of shit like integral sin(e ^ (x^2 * cos(e)) * tan(sqrt 5x)
I've always just thought of it as derivatives describe the rate of change and integrals the total of whatever it is that has been done.
Like if we're talking about an x that describes position in terms of t, time, dx/dt is the rate of change of position over change in time, or speed. Then ddx/dt is change in speed over change in time, or acceleration. And dddx/dt is rate of change in acceleration over change in time (iirc this is called jerk). And going the opposite way, integrating jerk gets acceleration, then speed, then back to position. But you lose information about the initial values for each along the way (eg speed doesn't care that you started 10m away from the origin, so integrating speed will only tell you about the change in position due to speed).
35 years after graduating from engineering school, this book helped me finally understand why calculus works, instead of just learning how to mechanically apply it.