Live data from Hacker News

I should have loved electrical engineering

blog.tdhttt.com

111–120 of 138 posts

Re: I should have loved electrical engineering

#111

Earlier quoted context omitted.

I went into EE wanting to learn how to design CPU’s and thought the analog side would be boring. However, control theory turned out to be my favorite class. Learning how negative feedback loops are everywhere was an eye opener. Also learning Laplace transforms was one of my first “holy shit this is freaking clever and cool” moments. Just like how parity bits in data streams can be used to detect AND correct errors.

Control theory was also one of my favorite classes that a low of software people should learn (at least the very basics). So many hand rolled heuristically driven if/else type systems that can simply be replaced more reliably with a PID.

Absolutely the worst control systems of all time have been written by software engineers that don’t understand control theory. The second worst control systems are designed by those who only know the PID heuristic, and can’t be bothered to model a little non-linearity from motor drives saturating.

Re: I should have loved electrical engineering

#112

The EE component of my CSE degree felt like a math degree in disguise. Calculus, linear algebra, differential equations, discrete mathematics... It was a long time ago but I remember it as three years of math prerequisites and Maxwell’s equations and then finally we could learn what a MOSFET is. Absolutely terrible. I just want to learn how circuits work and how to build a guitar amp! But noooooo I need to learn how…

You could do engineering without knowing about partial differential equations, or numerical methods. Most digital IC designers, FOGA guys etc do that. You would be missing some tools though. Not needing a tool ever doesn't mean it's not used anywhere else. You can't get into RF, proper signal integrity, or analog circuits without these and some more.

Re: I should have loved electrical engineering

#113

Earlier quoted context omitted.

Control theory was also one of my favorite classes that a low of software people should learn (at least the very basics). So many hand rolled heuristically driven if/else type systems that can simply be replaced more reliably with a PID.

I've played around with this over the years in my career but have found that tuning PID loops is very tricky, much trickier than creating a soup of if/else clauses and much less auditable to those who don't understand the math.

PID is standard in the industry, but the reality is it is infinitely easier to model in the discrete domain. The z-plane if math, but you don’t really need much math. Just model like a games developer. Simulate with a bit of JS or python. Add the motor saturation! Play with feedback and disturbances.

I just think this gives much better results. The model can be as simple or complex as you need, and we aren’t trapped in the linear response range. PID is good enough for many tasks, but it’s never good.

Re: I should have loved electrical engineering

#114
post #35

Earlier quoted context omitted.

Yeah, this kind of idea is why I’m dead against using things like the hydraulic analogy in early EE for anyone who is ever going to want to do more than the ‘hook some things up to an Arduino’ (or probably ESP32 these days) kind of level electronics. The gaps between the analogy and the real world actually make it harder to understand the fundamentals and just confuse people when you get to a deeper level understandi…

Once I ditched the hydraulic analogy and really tried to internalize charge, current, voltage, etc. is when I finally started to understand why the hydraulic analogy "works" but only for people who already understand electricity. Electricity behaves in many ways just like water (just at a significantly faster time scale) but I don't think it actually helped me learn how it all worked to start with.

This reminds me a lot of the car analogy that gets used to (poorly) teach object oriented programming.

Re: I should have loved electrical engineering

#115

Earlier quoted context omitted.

I went into EE wanting to learn how to design CPU’s and thought the analog side would be boring. However, control theory turned out to be my favorite class. Learning how negative feedback loops are everywhere was an eye opener. Also learning Laplace transforms was one of my first “holy shit this is freaking clever and cool” moments. Just like how parity bits in data streams can be used to detect AND correct errors.

Same on the laplace transforms. I was kinda mad we had learned any other way. It was a lot easier than whatever we were doing before mathematically! I wonder, how much control theory is there in CPU?

There's Boolean algebra but no control theory is needed for logic design.

One minor caveat is that most CPUs nowadays contain phase-locked loop (PLL) clock multipliers. Those fall into the domain of control theory but strictly speaking they're not part of the logic.

Re: I should have loved electrical engineering

#116
post #55

Earlier quoted context omitted.

Yeah - there was a massive filtering of the students between the 1st year entry, and the second year at my Uni. Largely down to people unable to handle the (not terribly) complex maths at that stage. I knew a number of folks in the first year who were very good at practical electronics, having come in from a technician side, but simply gave up due to the heavy maths load. It got more complex when doing Control Theory…

I went into EE wanting to learn how to design CPU’s and thought the analog side would be boring. However, control theory turned out to be my favorite class. Learning how negative feedback loops are everywhere was an eye opener. Also learning Laplace transforms was one of my first “holy shit this is freaking clever and cool” moments. Just like how parity bits in data streams can be used to detect AND correct errors.

Agreed on the Laplace transforms. They instantly turn linear differential equations into basic high school algebra problems. But they don't work for nonlinear problems.

Re: I should have loved electrical engineering

#117

Earlier quoted context omitted.

Control theory was also one of my favorite classes that a low of software people should learn (at least the very basics). So many hand rolled heuristically driven if/else type systems that can simply be replaced more reliably with a PID.

I've played around with this over the years in my career but have found that tuning PID loops is very tricky, much trickier than creating a soup of if/else clauses and much less auditable to those who don't understand the math.

Yes, but...

If you can model your problem with linear differential equations then control theory replaces the need for tuning. The coefficients you need just pop directly out of the analysis.

Re: I should have loved electrical engineering

#118
post #45

Earlier quoted context omitted.

My biggest criticism of EE pedagogy is that it tends to proceed from abstractions and then derive the whole world. This makes it a bit of a slog for a lot of students. I’d like to see an application-first approach that builds up principles from observed behavior. Like, measure the slip in an induction motor and then work out what’s going on there, instead of deriving motors from Maxwell’s equations.

That's a good point, too, I had a bunch of abstractions without applications in my head.

Its interestine, when you say abstractions. Could you explain what you mean by abstractions in this context and what do you mean by the underlying fundamentals.

Re: I should have loved electrical engineering

#119
post #27

Earlier quoted context omitted.

>Early classes on circuits in EE will usually take shortcuts using known circuit structures and simplified models. Might just be me, but I found it all clicked when we started learning the fundamentals underneath these abstractions. For me it was harder in the first classes because it's about memorizing poorly understood concepts, my brain prefers logically deriving complex concepts as a learning method.

Yeah, this kind of idea is why I’m dead against using things like the hydraulic analogy in early EE for anyone who is ever going to want to do more than the ‘hook some things up to an Arduino’ (or probably ESP32 these days) kind of level electronics. The gaps between the analogy and the real world actually make it harder to understand the fundamentals and just confuse people when you get to a deeper level understandi…

Heh, I used electrical circuit analogies when learning hydraulics for pipe networks in Civil Engineering. I struggled much less than the other students who didn't know any basic electrical stuff from physics classes.

Re: I should have loved electrical engineering

#120

Earlier quoted context omitted.

I've played around with this over the years in my career but have found that tuning PID loops is very tricky, much trickier than creating a soup of if/else clauses and much less auditable to those who don't understand the math.

Yes, but... If you can model your problem with linear differential equations then control theory replaces the need for tuning. The coefficients you need just pop directly out of the analysis.

Maybe I should add more context. I have specifically tried applying PID style feedback systems to computational problems, not controllers that interface with hardware, circuits, etc. My undergrad was in math and electrical engineering, I "pivoted" to software as a grad student (though I was always very involved in the software side of my department; I was a coder from when I was a kid.) The place I found it to work the best is with designing a homegrown autoscaler years before k8s ever became a viable thing for a company to play with [1]. Most of the problem domains I applied it to do not have linear models that can effectively model the theory. Yes I know that a PID is only proven to be stable when working with linear systems, but this is the reality of the problems I've worked with.

Eventually when if statements stop working I found that decision trees work great and XGBoost continues to be a great iteration of a decision tree.

[1]: I was an early hire at a tech unicorn and we built an autoscaler pretty early into the company's tenure. While it was a great success for a long time once k8s became established in the industry we had a really hard time training new talent to it and I left as we began a massive company-wide effort to move our workloads onto k8s.

Post reply on HN