Andymark Churros

[ratdude747]

Originally Posted by hrench

I also want to weigh-in on the 'build it and see if it breaks' philosphy that's being encouraged here.


That is NOT SCIENCE. What Science IS is using previous observation to determine what will happen deductively. The reason we engineers make books of statistics about materials and books of equations about stresses is because science works. If we design something that will work because we've used science, we've taught the kids the value of STEM.

if we design something with the guess that it might break or might not, then we didn't teach math, we didn't teach use of historical empirical statistics and instead we've taught 'trial and error.'

Not a good way to be an engineer.

Don't get me wrong, I was a 'farmboy' and stuff on a farm is most always pushed till it's about to break--or does. Seeing how stuff breaks is a great learning experience and I recommend it.

But engineering --doing the math--works better in the real world and I think that's what we're supposed to be teaching the kids.

As a senior in EET, I have to at least partially disagree.

More times than not, in EET at least, that IS how designs are implemented. Why? Because more times than not the math is, in practice, an ideal figure that is not as precise as one would like it to be. For example, this is why they still teach Smith charts in Electromagnetics classes (for those that don't know it's a graphical way of analyzing RF circuits), because while the modern math is easy given a good calculator (we used TI-86/89's), in reality, there are so many factors at play that the realistic accuracy is equivlent to using graphical methods.

Another example is with microcontrollers and DACs. While often times what the DAC is controlling (in my case, it was an VCO tuning an FM radio) can be modeled with an equation, in practice in a fair number of cases it works better to build the system and then through trial and error find the values needed. In my case, it was the 100 values corresponding to the 100 "channels" in the FM band. While, even with an optimized "scrolling" set of code to expidite the process, this took a couple of hours to find all the values (in the 12 bits the DAC would see), the result was a radio that despite being in an RF lab with poor reception, would pick up stations with reasonably clear sound. Using an equation to find the values probably would have worked, yes, but the results wouldn't have been as good.

Yes, math has a place, like initial designs (you have to stat somewhere), ballpark values (for situations that are hard to model), and feasibility analysis, but any good design is backed up with a tested and tuned prototype, which in some cases require some educated "guess and check" to get dialed in.

Relying on math alone may get a good grade on an exam but for actual design work, relying on math alone is a poor practice. To me, engineering is ultimately about good design work, not good test scores.

(yes, it's a long post, but I had something to say)