Is there a point to theoretical understanding?

Bhaskar Thiagarajan wrote:
> As with all things in engineering, "it depends".
> In my opinion, the value of understanding the underlying theory is
> invaluable. However, if the task on hand is to crank something out really
> fast, clearly taking shortcuts is the best approach. If I was running an
> engineering lab, I might allow the quick and dirty approach for prototypes
> or proof-of-concept efforts, but anything beyond that will affect the lab in
> the long term.
> 
> I'd also like to correct your interpretation of the various tools you've
> seen. They are just tools - not a replacement for understanding the theory.

That is in fact the interpretation I am supporting as well.  But the 
point is that the tools are getting quite impressive, even to one like 
myself who doesn't like to do anything unless I understand the theory 
behind it from the ground up.

> I'm fairly positive that people who understand the theory (for eg. Rick
> Lyons) don't go about designing filters by hand just because they know how
> to. They probably crank out their filters using Matlab or ScopeFIR just like
> the guy who can't spell conlution (:-)). The difference is that they know
> how to make the tool give the correct answer (is there such a thing?).

Or know when the tool isn't giving the right answer.

> Since you didn't have a very specific question - it's easy to ramble on. So
> I'll stop.
> 
> Cheers
> Bhaskar

Thanks for the input.

Good day!

-- 
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

Scott Stephens wrote:
> You left out performance. Do you know how they are implementing the 
> code? Have you ever tried Micro$oft example code, such as from their 
> javascript and winscript documents? It has subtle mistakes. Perhaps to 
> trip up script-kiddies?

Certainly I am aware that the code may not be optimum.  OTOH, it may be 
darn good.  Hard to say without having a look.

But there will be many cases where non-optimum code will be more than 
adequate, when not developing for consumer/cost sensitive mass produced 
apps.  Most of what I do is like this.  I can afford to throw 
overpowered CPUs at problems.  Trouble is, the lab takes this to an 
extreme, and fir instance many times they toss a PC104 system running 
LabView at something that could be handled with an 8-bit micro.  I'm 
simply seeking to strike a more sensible balance.

>> This has me a a little bit concerned.  I could spend a few months 
>> designing a system, by exercising all my theoretical knowledge.  But 
>> this essentially amounts to reinventing the wheel,
> 
> Aren't you getting paid by the feds? If I were you, I would milk it for 
> all I could. I was a gentleman and a scholar once. You deserve a good 
> hazing like I got.

Heh heh.  Indeed there is a lot of milk to drink, and I do.  But I use 
the opportunuty to learn and grow.  My boss just approved me to spend 
lab $$$ to go to two TI DSP workshops and an ADI workshop for a total 
bill of $2200.  This fall they'll pay my tuition if I want to take a 
formal course in DSP.

Actually they don't ever assign me to do tedious things like figure out 
how to compute coefficients, I give myself jobs like that.

I think I started this discussion almost averse to the tools I have 
recently discovered exist.  I think my point was disdain, that one could 
take credit for making an FIR filter without having a clue about how it 
works, when I have put effort into learning the theory and verifying the 
results very carefully.

But I had the same feelings about SPICE once.  Then I found out how much 
bench time it could save me, as well as getting close to a finished 
design for things that are just too complicated to breadboard.

SPICE hasn't made me abandon my theoretical study of circuit analysis, 
and I am still the one leading some of my fellow techs. out of the woods 
at times because I can do the math.

I think I may change my attitude and learn to like these tools, and yet 
always check the results against the theory like I do with SPICE.


>> In other words, does it further your career more to quickly produce 
>> results that work but you don't know why, vs. studying to develop the 
>> ability to know why things work, and to eventually make a few things 
>> which really exercise that understanding?  Things which couldn't be 
>> done by "cookbook engineering."
> 
> 
> Ask God - you don't know what you'll need to know tomorrow, or what will 
> pop out of the jungle to bite your ass. The people that really get ahead 
> are those that know how to get the scholars to serve them. And know how 
> to usurp the boss' authority and job.
> 
> Do you want to amuse yourself with gadgets or run your department, then 
> the DOE?

Gadgets, of course.

Thanks for the reply.

Good day!


-- 
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

Mac wrote:
>>This seems to be rare though, as most folks would rather just produce a
>>result.  My being the former way is why I'm in the field of fundamental
>>research rather than the product industry.  But this doesn't make me a
>>champion of productivity.
> 
> As you say, productivity isn't everything. Both kinds of people (and
> everyone in between) are important, those who prefer theory, those who
> prefer practice. In fact, you seem to be creating a false dichotomy. There
> are people with varying levels of pragmatism.

Indeed.  I probably slip a bit too far to the side of academics.  I tend 
to begin a review of the first-principles analysis of an op-amp circuit 
when there is really no need, and just plucking two resistors out of a 
drawer and getting on with it would be a better idea.

>>This has me a a little bit concerned.  I could spend a few months
>>designing a system, by exercising all my theoretical knowledge.  But
>>this essentially amounts to reinventing the wheel, if the tools are
>>available to do it for me, and there is no need for a highly optimized
>>solution.
> 
> Well, yes. But maybe you can save money by not buying the tools. If you
> only need to design one filter, and the tools cost thousands, this could
> be a big deal.

Good point.

>>Meanwhile the guy down the hall produces a result in two weeks, and
>>tells his boss "look I make a custom DSP digital filtering machine" when
>>he can't even spell c-o-n-v-o-l-u-t-i-o-n.  I wonder if someone like
>>myself who really *wants* to start from scratch just belongs in academia
>>or someplace where getting off on intellectual tangents is the point
>>rather than an impedement.  Fortunately, Sandia is close enough to that
>>that I don't get into any trouble here if I take my time.
>>
>>
> 
> Well, it sounds as though you belong in academia or a research lab. Maybe
> you can move on to harder problems that haven't already been codified into
> convolution "wizards" or something. Maybe you can write the papers that
> others use to create wizards for more challenging problems. On the other
> hand, if you think you'd be happy in industry, then I'm sure industry
> would be happy to have you.  ;-)

Research lab, yes!

> I don't know what a lock-in is.

Here's one of many brief web intros:

http://www.boselec.com/products/siglimwhat.shtml

> Sounds like a PLL?

Definitely not.  A PLL is a servo loop that adjusts the frequency of an 
oscillator to make its phase track an input frequency.

The lock-in is a synchronous demodulator, for recovering signals buried 
in noise.  Extremely useful for scientific measurements of barely 
observable signals.

>>The fellow did a fine job considering his lack of theoretical
>>understanding, it is important to note.  But I couldn't help but to
>>wonder how wise it was to have someone build the thing who didn't
>>understand the very basic theory of the system they were building?  Yet
>>he produced a result that met the goals.
> 
> Sounds like it worked, although 3 years is a long time. A project that
> lasts 3 years could end up having parts go obsolete before it is even
> finished.  ;-)

Not in a research lab.  Nothing cutting edge here.  Just op-amps and 
oscillators.  Oh, and only one unit produced.

>>Is this way of doing things common?
> 
> Well, if a company needs to complete some task, and no one in the company
> is perfect for the job, management has to try to find the best person to
> do it. Maybe they can outsource it or hire a contractor. Or, maybe, if
> there is a resourceful person, a manager might feel confident that this
> resourceful person can pick up enough of the theory on the fly to complete
> the task. This can be a reasonable decision, but the details matter. On
> several occasions I have been that resourceful person who was assigned a
> task which forced me to learn new things. So far it has worked out both
> for me and for my employer. But it is precisely because I payed attention
> in school that I can figure these things out. So, in the end, theory and
> pragmatism are both very important. Certainly, anyone who has contempt for
> theory is not going to get very far as an engineer. At the same time,
> anyone who has contempt for the end goals which allow the company to stay
> in business is not going to get very far, either.

Interesting.

Thanks for the response.

Have a good day!



-- 
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

Tim Shoppa wrote:
> Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message news:<c27t320mkm@enews1.newsguy.com>...
> 
>>Why then should one study the theory and learn how to calculate filter 
>>coefficients by hand?
> 
> 
> That's a little like asking why we have sin and cos buttons on our
> calculators instead of having to look up the numbers in tables anymore.
> 
> At the same time it's really good to know that cos^2+sin^2 = 1, and
> probably even that sin(x) ~ x and cos(x) ~ 1-x^2 for small x.  Yes,
> these factoids come from theory, but those factoids become most useful
> when you are solving real problems.
> 
> Your two-pronged approach, where you learn the tools *and* pick up theory
> (might as well be from the school of hard knocks!) at the same time
> sounds great.  Theory without tools isn't completely pointless, but
> when both come together it's a lot more fun.
> 
> Tim.


Yes.  I think I was shocked to see what tools were available, then 
responded with aversion.  Now I think I may actually benefit from them. 
  But I will learn the theory as well.  I don't hand calculate a minimax 
polynomial approximation every time I need a sine or cosine, I 
definitely use my computulator.

But I never could stand not knowing how those buttons worked, and it was 
almost a lifesaving relief when I finally got to calc3 and numerical 
analysis courses that made it all clear.  Of course then I spent far 
more time than required to do my homework experimenting with the 
concepts learned.  This certainly paid off at test time.



Thanks for the input.



-- 
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

Chris Carlen wrote:

> Why then should one study the theory and learn how to calculate filter 
> coefficients by hand?  

For me there are two reasons.  The first is that things 
often don't work out the way the recipe says it will and 
without theory you may be lost as to why.

The second and more fundamental depends on whether you wish 
to innovate.  If so then the theory is absolutely 
necessasary and there is no such thing as too much of it. 
If the goal is to crank out answers within a well defined 
and supported domain (which I don't intend to demean as a 
goal) then it may not be all that necessasary but coming up 
with something new is what it's all about for me and always 
has been.  Without all the theory I can get under my belt my 
chances of meeting that goal are negligable.  It's a tough 
enough endeavor with it.


Bob
-- 

"Things should be described as simply as possible, but no 
simpler."

                                              A. Einstein

"Scott Stephens" <scottxs@comcast.net> schreef in bericht
news:7hR1c.177714$jk2.652553@attbi_s53...
> Fred Marshall wrote:

> > "Better is the enemy of good enough".  I love to suggest that to
engineers!
>
> Simpler is better. Less things to surprise you.

So, simpler is the enemy of good enough.

<g>


-- 
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

> 
> > "Tim Shoppa" <shoppa@trailing-edge.com> wrote in message
> > news:bec993c8.0403051046.20845ea8@posting.google.com...
> >> probably even that sin(x) ~ x and cos(x) ~ 1-x^2 for small x.
> 
>                                      cos(x) ~ 1 - 0.5*x^2 for small x.

Oops, my mistake.  I'll get back to milking my spherical cow now...

Tim.

Frank Bemelman wrote:

> "Scott Stephens" <scottxs@comcast.net> schreef in bericht
> news:7hR1c.177714$jk2.652553@attbi_s53...
> 
>>Fred Marshall wrote:
> 
> 
>>>"Better is the enemy of good enough".  I love to suggest that to
> 
> engineers!
> 
>>Simpler is better. Less things to surprise you.
> 
> 
> So, simpler is the enemy of good enough.

You could say that, but then, substituting a good-enough Simpler for 
Good Enough, you could conclude Better is the enemy of Simpler, and then 
substitute to conclude Better is the enemy of Better.

Syllogisms based on premises of derived generalizations have a similar 
problem as using cook-book code and compilers. If you filter out too 
much detail, or process data with sufficient resolution, you can't 
exercise good judgment.

It takes detailed understanding of a problem and the solution to avoid 
implementation errors.

-- 
Scott

**********************************

DIY Piezo-Gyro, PCB Drill Bot & More Soon!

http://home.comcast.net/~scottxs/

**********************************

On Thu, 04 Mar 2004 10:38:27 -0800, Chris Carlen
<crcarle@BOGUS.sandia.gov> wrote:


>This has me a a little bit concerned.  I could spend a few months 
>designing a system, by exercising all my theoretical knowledge.  But 
>this essentially amounts to reinventing the wheel, if the tools are 
>available to do it for me, and there is no need for a highly optimized 
>solution.  Meanwhile the guy down the hall produces a result in two 
>weeks, and tells his boss "look I make a custom DSP digital filtering 
>machine" when he can't even spell c-o-n-v-o-l-u-t-i-o-n.  I wonder if 
>someone like myself who really *wants* to start from scratch just 
>belongs in academia or someplace where getting off on intellectual 
>tangents is the point rather than an impedement.  Fortunately, Sandia is 
>close enough to that that I don't get into any trouble here if I take my 
>time.
>

Who do you think the boss prefers: the guy who did it in two weeks, or
the guy who wants to study the problem for nine months or so?

It all depends on where you are in the abstraction stack, and what
your real goals are. I don't write PC programs in hex, and I don't
design compilers: I just use the easiest programming tools I can find.
Similarly, if you are designing a product that needs, say, an adaptive
equalizer, and you can get a nice hunk of DSP code somewhere, then as
an engineer you can just use it without guilt. If your business is to
design and sell adaptive equalizer algorithms, then you'd better dig
deeper.

Nowadays, if you are doing a complex, multi-discipline design, you've
got to rely on all sorts of lower-level things you don't really
understand except on a functional level. The little boards I'm
designing today would have taken teams of engineers 20 years ago, and
would have filled up racks. Yes, you had better know about
quantization and windowing and aliasing, but you don't have to do all
the low-level stuff yourself, any more than you have to understand
semiconductor processing to use opamps.

John

I read in sci.electronics.design that John Larkin <jjlarkin@highlandSNIP
techTHISnologyPLEASE.com> wrote (in <vb7k40l9131ug8lkmvd81rof57vq3j09uu@
4ax.com>) about 'Is there a point to theoretical understanding?', on
Sat, 6 Mar 2004:

>Who do you think the boss prefers: the guy who did it in two weeks, or 
>the guy who wants to study the problem for nine months or so? 

The boss would probably prefer Fred Bloggs, for his ability to do it in
two shakes, but there might be team interaction problems. (;-)

Virtually 'seeing' the way to do things instantaneously requires a
balanced mixture of theoretical and practical knowledge. For example,
recently I wanted to know the analytical expression for the magnetic
field outside a solenoid (inside is easy!). It turns out to involve
elliptic functions, so should I go and study elliptic functions for a
week or three?  

Aha! That applies to a *cylindrical* solenoid; the expression for a
square-section solenoid is EASY! So easy, I virtually already know it.
And since I'm mostly interested in the field pattern at distances much
larger than the dimensions of the solenoid, the shape makes very little
difference.
-- 
Regards, John Woodgate, OOO - Own Opinions Only. 
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk