Math and electrical desgin

On Sunday, March 29, 2020 at 9:51:49 AM UTC+11, jla...@highlandsniptechnology.com wrote:
On Sat, 28 Mar 2020 14:22:12 -0700 (PDT), Flyguy <tomseim2g@gmail.com
wrote:

On Saturday, March 28, 2020 at 2:01:15 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 28 Mar 2020 13:06:24 -0700 (PDT), George Herold
ggherold@gmail.com> wrote:

On Friday, March 27, 2020 at 6:25:46 PM UTC-4, pcdh...@gmail.com wrote:

<snip>

Personally, it was vital. Not all the time, but when math is needed there is no substitute. Try explaining complex impedance to someone w/o math; it just won't make any sense.

I think I could do that, purely visually with no math.

Or how a capacitor can conduct current. Or how a transformer works.

Those can be explained pretty well without math.

Any explanation of how a transformer works that doesn't involve the transformer equations

V1= L1.dI1/dt + M.dI2/dt

V2= M.dI1/dt + L2.dI2/dt

turns out to be eventually misleading. It took me years to get onto that, and it's definitely a case where math is essential.

John Larkin doesn't seem to have got there yet.

--
Bill Sloman, Sydney
 
On Sunday, March 29, 2020 at 10:43:37 AM UTC+11, Rick C wrote:
On Saturday, March 28, 2020 at 7:32:47 PM UTC-4, Clifford Heath wrote:
On 29/3/20 10:00 am, jlarkin@highlandsniptechnology.com wrote:
On Sat, 28 Mar 2020 15:00:02 -0700 (PDT), Roger_the_Dodger
cresswellavenue@talktalk.net> wrote:
For a USB oscilloscope I designed I had to get into signal processing.
I had to use a Fast Fourier Transform for displaying a frequency graph.

Did you program the FFT yourself from first principles, or did you
look up the code somewhere?

A Discrete Fourier Transform is easy to program from first principles,
as soon as you know what it actually is. FFT not so much, but having
done a DFT at least gives you the intuition about how an FFT is possible.

An FFT is not so hard. You just have to get your head wrapped around the permutations. I can't imaging being the guy who first came up with it. Likely recognized something in the sequence of sines related to something else in math he was familiar with. That's what the FFT is about, decomposing the DFT sines into operations that can be shared among all the harmonics.

Don't recall the name, but I think this was before it was very useful given the state of computing, so I don't know that the guy was looking for a way to speed up the DFT. I suppose a wikipedia search would answer that question.

Danielson and Lanczos published in 1942, Cooley-Tukey didn't publish until 1965.

https://pdfs.semanticscholar.org/5bac/973284d452fc7059f65bed02a935fd983c19.pdf

Lanczos is famous for a lot of stuff like that - I've known about the FFT story for many years now. I cited his 1957 book on "Applied Analysis" in my Ph.D. thesis.

--
Bill Sloman, Sydney
 
On Saturday, March 28, 2020 at 7:39:38 PM UTC-7, Bill Sloman wrote:
On Sunday, March 29, 2020 at 9:51:49 AM UTC+11, jla...@highlandsniptechnology.com wrote:

On Saturday, March 28, 2020 at 2:01:15 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 28 Mar 2020 13:06:24 -0700 (PDT), George Herold
ggherold@gmail.com> wrote:

On Friday, March 27, 2020 at 6:25:46 PM UTC-4, pcdh...@gmail.com wrote:

snip

Personally, it was vital. Not all the time, but when math is needed there is no substitute. Try explaining complex impedance to someone w/o math; it just won't make any sense.

I think I could do that, purely visually with no math.

Or how a capacitor can conduct current. Or how a transformer works.

Those can be explained pretty well without math.

Any explanation of how a transformer works that doesn't involve the transformer equations

V1= L1.dI1/dt + M.dI2/dt

V2= M.dI1/dt + L2.dI2/dt

turns out to be eventually misleading. It took me years to get onto that, and it's definitely a case where math is essential.

John Larkin doesn't seem to have got there yet.

--
Bill Sloman, Sydney

Anything that involves differential equations IS NOT "simple math." Then try thinking in terms of electromagnetic fields and vector calculus.
 
On Sun, 29 Mar 2020 00:49:57 +0000, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

On 28/03/20 22:08, Joerg wrote:
On 2020-03-28 13:38, blocher@columbus.rr.com wrote:
On Friday, March 27, 2020 at 6:00:10 PM UTC-4, Rick C wrote:

[...]


So your work is not so much circuit design as it is system design?

I like to think I straddle circuits and systems.  I am decent at both
but certainly not an expert at analog.  The problem in my company is
that there is not enough work in circuit design to keep one always
busy.  I also think that most circuit problems are better solved
through a system approach.  If you get the system concept wrong, then
the circuit is going to be wrong.  If you know what you want at the
high level, it is easier to tell if your circuit design is adequate.


Amen!

Top-down is generally the only approach that really works. Now we'll have to
explain that to the next generations. All the ones who have served in the
military don't need to be told, they know this already.

You need top-down and bottom-up simultaneously.

It's best to be fluid and confused for a while before getting
rigorous. Bottom-level thinking about a new problem can create
insights that can affect top-level architectures and requirements, and
specs. How can you create requirements if you don't know what's
possible?

Bottom-up allows you to reuse known working
components, processes and concepts.

Or invent new ones.

Top-down on its own can lead to requiring
impossible components.

Top-level requirements documents are very difficult to change in some
organizations. They require signoff by too many managers. Important or
just sensible changes can go into a swirl of management approvals and
disappear in the process.

I recently discovered a semiconductor processing system that has four
expensive energy metrology subsystems that never worked but have been
installed in all systems since 2003. My gear collects useless data
from them and sends it to a computer that ignores it. It would be
impossible to move enough management to fix this. Figure roughly a
million dollars a year wasted for 17 years now.

Bottom-level things, at the board level, are easier to fix. Just do
it. Management can't read schematics.



--

John Larkin Highland Technology, Inc

The cork popped merrily, and Lord Peter rose to his feet.
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"
 
Tom Gardner <spamjunk@blueyonder.co.uk> wrote in
news:nmSfG.137170$%86.51142@fx24.am4:

On 28/03/20 22:48, Phil Hobbs wrote:
Instinct is super useful for generating ideas.  We come up with
some scheme by instinct, but then test it by math.  The math
involved is super familiar--what's the noise floor, the
bandwidth, the settling time, and so on.  It's the familiarity
that makes that seem like it's the same as design instinct, but
it isn't.

Very true, IMNSHO.

Practice without theory is blind fumbling.
Theory without practice is mental masturbation.
I exaggerate, of course.

He said as he wiggled his hands up and down above his head...

Don't jack your brain.
 
George Herold <ggherold@gmail.com> wrote in
news:494f975a-54da-46d1-bdfb-9eaeb783919b@googlegroups.com:

Designing something cool with a few smart people at a whiteboard
is the

most fun you can have standing up.
Amen,
George H.

Barefoot water skiing.

Running off a whole rack at pool.
 
On Saturday, March 28, 2020 at 1:26:34 PM UTC-7, blo...@columbus.rr.com wrote:

> The thing that is tough about linear algebra is that there are not a lot of applications that continually reinforce your expertise on the subject.

Any multivariate system quickly involves linear algebra; the FFT is a matrix,
and multiply-accumulate operations are pretty important (inner product) in
signal processing.
 
On Sat, 28 Mar 2020 19:58:40 -0700 (PDT), Flyguy <tomseim2g@gmail.com>
wrote:

On Saturday, March 28, 2020 at 7:39:38 PM UTC-7, Bill Sloman wrote:
On Sunday, March 29, 2020 at 9:51:49 AM UTC+11, jla...@highlandsniptechnology.com wrote:

On Saturday, March 28, 2020 at 2:01:15 PM UTC-7, jla...@highlandsniptechnology.com wrote:
On Sat, 28 Mar 2020 13:06:24 -0700 (PDT), George Herold
ggherold@gmail.com> wrote:

On Friday, March 27, 2020 at 6:25:46 PM UTC-4, pcdh...@gmail.com wrote:

snip

Personally, it was vital. Not all the time, but when math is needed there is no substitute. Try explaining complex impedance to someone w/o math; it just won't make any sense.

I think I could do that, purely visually with no math.

Or how a capacitor can conduct current. Or how a transformer works.

Those can be explained pretty well without math.

Any explanation of how a transformer works that doesn't involve the transformer equations

V1= L1.dI1/dt + M.dI2/dt

V2= M.dI1/dt + L2.dI2/dt

turns out to be eventually misleading. It took me years to get onto that, and it's definitely a case where math is essential.

John Larkin doesn't seem to have got there yet.

--
Bill Sloman, Sydney

Anything that involves differential equations IS NOT "simple math." Then try thinking in terms of electromagnetic fields and vector calculus.

Thinking about differential equations is intuitive and easily
explained to people who can visualize things like mass and velocity.
After that, let computers do the actual work. Anything interesting is
nonlinear anyhow.

I taught one course in nonlinear computer simulation that consisted of
the students all coding the filling of a toilet tank. They all did it
well and enjoyed it.



--

John Larkin Highland Technology, Inc

The cork popped merrily, and Lord Peter rose to his feet.
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"
 
On Sun, 29 Mar 2020 00:55:47 +0000, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

On 28/03/20 22:48, Phil Hobbs wrote:
Instinct is super useful for generating ideas.  We come up with some scheme by
instinct, but then test it by math.  The math involved is super familiar--what's
the noise floor, the bandwidth, the settling time, and so on.  It's the
familiarity that makes that seem like it's the same as design instinct, but it
isn't.

Very true, IMNSHO.

Practice without theory is blind fumbling.

It built aqueducts, ships, roads, cathedrals, all sorts of stuff.

>Theory without practice is mental masturbation.

Well, maybe less useful.

I exaggerate, of course.

--

John Larkin Highland Technology, Inc

The cork popped merrily, and Lord Peter rose to his feet.
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"
 
On Sunday, March 29, 2020 at 2:31:56 PM UTC+11, jla...@highlandsniptechnology.com wrote:
On Sun, 29 Mar 2020 00:55:47 +0000, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 28/03/20 22:48, Phil Hobbs wrote:
Instinct is super useful for generating ideas.  We come up with some scheme by
instinct, but then test it by math.  The math involved is super familiar--what's
the noise floor, the bandwidth, the settling time, and so on.  It's the
familiarity that makes that seem like it's the same as design instinct, but it
isn't.

Very true, IMNSHO.

Practice without theory is blind fumbling.

It built aqueducts, ships, roads, cathedrals, all sorts of stuff.

Most of which fell down several times before the builders fumbled into rules that worked.

Math is a much cheaper way of finding out that something isn't going to work.

<snip>

--
Bill Sloman, Sydney
 
On 29/03/20 04:09, jlarkin@highlandsniptechnology.com wrote:
On Sun, 29 Mar 2020 00:49:57 +0000, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 28/03/20 22:08, Joerg wrote:
On 2020-03-28 13:38, blocher@columbus.rr.com wrote:
On Friday, March 27, 2020 at 6:00:10 PM UTC-4, Rick C wrote:

[...]


So your work is not so much circuit design as it is system design?

I like to think I straddle circuits and systems.  I am decent at both
but certainly not an expert at analog.  The problem in my company is
that there is not enough work in circuit design to keep one always
busy.  I also think that most circuit problems are better solved
through a system approach.  If you get the system concept wrong, then
the circuit is going to be wrong.  If you know what you want at the
high level, it is easier to tell if your circuit design is adequate.


Amen!

Top-down is generally the only approach that really works. Now we'll have to
explain that to the next generations. All the ones who have served in the
military don't need to be told, they know this already.

You need top-down and bottom-up simultaneously.

It's best to be fluid and confused for a while before getting
rigorous. Bottom-level thinking about a new problem can create
insights that can affect top-level architectures and requirements, and
specs. How can you create requirements if you don't know what's
possible?


Bottom-up allows you to reuse known working
components, processes and concepts.

Or invent new ones.


Top-down on its own can lead to requiring
impossible components.


Top-level requirements documents are very difficult to change in some
organizations. They require signoff by too many managers. Important or
just sensible changes can go into a swirl of management approvals and
disappear in the process.

Yes to all the above.

The response to such "waterfall" processes is are the
various "agile" processes. The agile processes do have
some real advantages w.r.t. waterfall, but the zealous
acolytes are too dumb to realise that they have different
disadvantages.

A key issue is the absolute reliance on test-driven
design and a bottom-up approach.

TDD is great for ensuring your last low-level tweak
didn't change things - but it is of little use in
getting the right design. Too many people think "it
works because it passes the tests", without giving
any thought to the comprehensiveness of the tests.

As old timers know, "you can't test quality into a
product".


I recently discovered a semiconductor processing system that has four
expensive energy metrology subsystems that never worked but have been
installed in all systems since 2003. My gear collects useless data
from them and sends it to a computer that ignores it. It would be
impossible to move enough management to fix this. Figure roughly a
million dollars a year wasted for 17 years now.

When creating a new plant, Intel duplicates absolutely
everything, down to the ridiculous last detail (e.g.
exact type of obsolete PC). They know how fragile
semiconductor plants are, and want to remove all
possible variables.


Bottom-level things, at the board level, are easier to fix. Just do
it. Management can't read schematics.

Such low-level fixes can have "unintended consequences"
at the system level.
 
On 29/03/20 04:31, jlarkin@highlandsniptechnology.com wrote:
On Sun, 29 Mar 2020 00:55:47 +0000, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 28/03/20 22:48, Phil Hobbs wrote:
Instinct is super useful for generating ideas.  We come up with some scheme by
instinct, but then test it by math.  The math involved is super familiar--what's
the noise floor, the bandwidth, the settling time, and so on.  It's the
familiarity that makes that seem like it's the same as design instinct, but it
isn't.

Very true, IMNSHO.

Practice without theory is blind fumbling.

It built aqueducts, ships, roads, cathedrals, all sorts of stuff.

Er, no.

Wells cathedral is near me. There are strange additions
that became necessary because it rapidly started falling
down.

It took a long time for architects to understand the finer
points (literally!) of flying buttresses and why they are
necessary. Lots of trial and error (i.e. blind fumbling)
before that.

I've seen the Wasa, and ought to see the Mary Rose.
Both were high-prestige warships that sank on their
first voyage.

And the Tacoma narrows bridge is near you.


Theory without practice is mental masturbation.

Well, maybe less useful.

I exaggerate, of course.
 
On 2020-03-28 23:31, jlarkin@highlandsniptechnology.com wrote:
On Sun, 29 Mar 2020 00:55:47 +0000, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 28/03/20 22:48, Phil Hobbs wrote:
Instinct is super useful for generating ideas.  We come up with some scheme by
instinct, but then test it by math.  The math involved is super familiar--what's
the noise floor, the bandwidth, the settling time, and so on.  It's the
familiarity that makes that seem like it's the same as design instinct, but it
isn't.

Very true, IMNSHO.

Practice without theory is blind fumbling.

It built aqueducts, ships, roads, cathedrals, all sorts of stuff.

Not by fiddling, though--experience accumulates. Even a pyramid will
fall down if you build it too steep.
<https://en.wikipedia.org/wiki/Meidum_Pyramid>

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com
 
On 2020-03-28 23:12, DecadentLinuxUserNumeroUno@decadence.org wrote:
George Herold <ggherold@gmail.com> wrote in
news:494f975a-54da-46d1-bdfb-9eaeb783919b@googlegroups.com:

Designing something cool with a few smart people at a whiteboard
is the

most fun you can have standing up.
Amen,
George H.

Barefoot water skiing.

Running off a whole rack at pool.

You've apparently never done it.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com
 
Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote in
news:941f4f12-7f59-97fb-6f0f-77308cc3a347@electrooptical.net:

On 2020-03-28 23:31, jlarkin@highlandsniptechnology.com wrote:
On Sun, 29 Mar 2020 00:55:47 +0000, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 28/03/20 22:48, Phil Hobbs wrote:
Instinct is super useful for generating ideas.  We come up
with some scheme by instinct, but then test it by math.  The
math involved is super familiar--what's the noise floor, the
bandwidth, the settling time, and so on.  It's the familiarity
that makes that seem like it's the same as design instinct, but
it isn't.

Very true, IMNSHO.

Practice without theory is blind fumbling.

It built aqueducts, ships, roads, cathedrals, all sorts of stuff.

Not by fiddling, though--experience accumulates. Even a pyramid
will fall down if you build it too steep.
https://en.wikipedia.org/wiki/Meidum_Pyramid

Cheers

Phil Hobbs

Yes heavy granite acts that way.

Those boys found that out, especially on a not quite ultra stable
base foundation.

If one were to build it from hollow, carbon fiber side panel
'stones', it would handle any side wall configuration angle and
survive.

Could probably use foamed concrete and succeed too.

Not blind fumbling. I studied pyramids most of my life. Lincoln
logs too. ;-)

One of my nyms was 'TutAmongUs', not that he had a pyramid. My
pyramid would have solar panel sides. Give it the same, multi-hued
color as a CPU die or memory die.
 
Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote in
news:fd467d02-06d6-78e5-bd05-d420a9f8948f@electrooptical.net:

On 2020-03-28 23:12, DecadentLinuxUserNumeroUno@decadence.org
wrote:
George Herold <ggherold@gmail.com> wrote in
news:494f975a-54da-46d1-bdfb-9eaeb783919b@googlegroups.com:

Designing something cool with a few smart people at a whiteboard
is the

most fun you can have standing up.
Amen,
George H.

Barefoot water skiing.

Running off a whole rack at pool.


You've apparently never done it.

Cheers

Phil Hobbs

Going over my design ideas with supportive co-engineers is one
thing. Having one or more unable to see what you've come up with
'providing' stupid input is entirely another, and therefore is not a
favorite thing to do. I'll design it, they'll do their pieces. No
need for a white board discussion, just a white board project
declaration, and any issues they have can be brought up while they
are doing their assigned part.

You've apparently moved toward the Larkin attitude of presumimg
things which you know no facts regarding as it relates to me. That
is a character and integrity hit you do not want. But you live as
you like.
 
On 29/03/20 12:48, Phil Hobbs wrote:
On 2020-03-29 05:54, Tom Gardner wrote:
On 29/03/20 04:31, jlarkin@highlandsniptechnology.com wrote:
On Sun, 29 Mar 2020 00:55:47 +0000, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 28/03/20 22:48, Phil Hobbs wrote:
Instinct is super useful for generating ideas.  We come up with some scheme by
instinct, but then test it by math.  The math involved is super
familiar--what's
the noise floor, the bandwidth, the settling time, and so on.  It's the
familiarity that makes that seem like it's the same as design instinct, but it
isn't.

Very true, IMNSHO.

Practice without theory is blind fumbling.

It built aqueducts, ships, roads, cathedrals, all sorts of stuff.

Er, no.

Wells cathedral is near me. There are strange additions
that became necessary because it rapidly started falling
down.

It took a long time for architects to understand the finer
points (literally!) of flying buttresses and why they are
necessary. Lots of trial and error (i.e. blind fumbling)
before that.

I've seen the Wasa, and ought to see the Mary Rose.
Both were high-prestige warships that sank on their
first voyage.

And the Tacoma narrows bridge is near you.

In the sense of the distance being considerably more than the total length of
Great Britain. ;)

Not if you use the Mercator projection :)


(Tacoma and SF are 777 miles apart if you take the fastest route, i.e.
Interstate 5.)

Not according to intuition :)
 
On 2020-03-29 05:54, Tom Gardner wrote:
On 29/03/20 04:31, jlarkin@highlandsniptechnology.com wrote:
On Sun, 29 Mar 2020 00:55:47 +0000, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 28/03/20 22:48, Phil Hobbs wrote:
Instinct is super useful for generating ideas.  We come up with some
scheme by
instinct, but then test it by math.  The math involved is super
familiar--what's
the noise floor, the bandwidth, the settling time, and so on.  It's the
familiarity that makes that seem like it's the same as design
instinct, but it
isn't.

Very true, IMNSHO.

Practice without theory is blind fumbling.

It built aqueducts, ships, roads, cathedrals, all sorts of stuff.

Er, no.

Wells cathedral is near me. There are strange additions
that became necessary because it rapidly started falling
down.

It took a long time for architects to understand the finer
points (literally!) of flying buttresses and why they are
necessary. Lots of trial and error (i.e. blind fumbling)
before that.

I've seen the Wasa, and ought to see the Mary Rose.
Both were high-prestige warships that sank on their
first voyage.

And the Tacoma narrows bridge is near you.

In the sense of the distance being considerably more than the total
length of Great Britain. ;)

(Tacoma and SF are 777 miles apart if you take the fastest route, i.e.
Interstate 5.)

Cheers

Phil Hobbs

(Who used to drive that route a fair amount, long ago.)


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com
 
On 2020-03-29 07:59, DecadentLinuxUserNumeroUno@decadence.org wrote:
Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote in
news:fd467d02-06d6-78e5-bd05-d420a9f8948f@electrooptical.net:

On 2020-03-28 23:12, DecadentLinuxUserNumeroUno@decadence.org
wrote:
George Herold <ggherold@gmail.com> wrote in
news:494f975a-54da-46d1-bdfb-9eaeb783919b@googlegroups.com:

Designing something cool with a few smart people at a whiteboard
is the

most fun you can have standing up.
Amen,
George H.

Barefoot water skiing.

Running off a whole rack at pool.


You've apparently never done it.

Cheers

Phil Hobbs


Going over my design ideas with supportive co-engineers is one
thing. Having one or more unable to see what you've come up with
'providing' stupid input is entirely another, and therefore is not a
favorite thing to do. I'll design it, they'll do their pieces. No
need for a white board discussion, just a white board project
declaration, and any issues they have can be brought up while they
are doing their assigned part.

Which is not what I was referring to, at all, and sounds boring, I agree.

Collaborative design at a whiteboard may go something like this example
of a phase-sensitive laser microscope. Somebody says, "How about using
a heterodyne interferometer with an acousto-optic cell and a Wollaston
prism to recombine the beams? That way we can make the whole thing
common-path so we can use normal galvo scanning." (A real example from
long ago--an English guy improving on an idea of mine.)

Then everybody chimes in with questions such as the following.

"You'll need at least a milliwatt of laser power to get to the shot
noise in that bandwidth. That's about 200 kilowatts per square
centimetre--will your sample stand that?" (Leading to a discussion about
3-D heat conduction in solids.)

"The topological phase shift in the galvo scanner will screw up the beam
recombination in the return path, won't it?" (This is a real issue that
constrains the scan range.)

This isn't rock-throwing at all--everybody wants the thing to work, and
ideally they're all friends. After half an hour or so, everybody has a
much better idea of whether the scheme can be made to work, and the
final version probably doesn't look much like the initial proposal.

It's better if there are two or three schemes being discussed, along
with lots of ideas for improvements. You also need a few harebrained
notions tossed in. (*)

It only works if nobody minds having their pet ideas demolished, because
that's definitely going to happen. Personally I'm very glad when it
happens to me, because it may save a lot of wasted work. I have lots of
ideas, so I'm not at all attached to the bad ones.

You've apparently moved toward the Larkin attitude of presumimg
things which you know no facts regarding as it relates to me. That
is a character and integrity hit you do not want. But you live as
you like.

Not intending to be insulting at all, but as your first paragraph
suggests, you've probably never done what I'm attempting to describe.
(Or perhaps I just didn't describe it well enough initially.)

Cheers

Phil Hobbs

(*) The use of helicopter propwash to knock ice off high-tension wires
allegedly came out of a discussion like that.

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com
 
On Sunday, March 29, 2020 at 8:47:30 AM UTC-4, Phil Hobbs wrote:
On 2020-03-29 07:59, DecadentLinuxUserNumeroUno@decadence.org wrote:
Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote in
news:fd467d02-06d6-78e5-bd05-d420a9f8948f@electrooptical.net:

On 2020-03-28 23:12, DecadentLinuxUserNumeroUno@decadence.org
wrote:
George Herold <ggherold@gmail.com> wrote in
news:494f975a-54da-46d1-bdfb-9eaeb783919b@googlegroups.com:

Designing something cool with a few smart people at a whiteboard
is the

most fun you can have standing up.
Amen,
George H.

Barefoot water skiing.

Running off a whole rack at pool.


You've apparently never done it.

Cheers

Phil Hobbs


Going over my design ideas with supportive co-engineers is one
thing. Having one or more unable to see what you've come up with
'providing' stupid input is entirely another, and therefore is not a
favorite thing to do. I'll design it, they'll do their pieces. No
need for a white board discussion, just a white board project
declaration, and any issues they have can be brought up while they
are doing their assigned part.

Which is not what I was referring to, at all, and sounds boring, I agree.

Collaborative design at a whiteboard may go something like this example
of a phase-sensitive laser microscope. Somebody says, "How about using
a heterodyne interferometer with an acousto-optic cell and a Wollaston
prism to recombine the beams? That way we can make the whole thing
common-path so we can use normal galvo scanning." (A real example from
long ago--an English guy improving on an idea of mine.)

Then everybody chimes in with questions such as the following.

"You'll need at least a milliwatt of laser power to get to the shot
noise in that bandwidth. That's about 200 kilowatts per square
centimetre--will your sample stand that?" (Leading to a discussion about
3-D heat conduction in solids.)

"The topological phase shift in the galvo scanner will screw up the beam
recombination in the return path, won't it?" (This is a real issue that
constrains the scan range.)

This isn't rock-throwing at all--everybody wants the thing to work, and
ideally they're all friends. After half an hour or so, everybody has a
much better idea of whether the scheme can be made to work, and the
final version probably doesn't look much like the initial proposal.

It's better if there are two or three schemes being discussed, along
with lots of ideas for improvements. You also need a few harebrained
notions tossed in. (*)

It only works if nobody minds having their pet ideas demolished, because
that's definitely going to happen. Personally I'm very glad when it
happens to me, because it may save a lot of wasted work. I have lots of
ideas, so I'm not at all attached to the bad ones.

You've apparently moved toward the Larkin attitude of presumimg
things which you know no facts regarding as it relates to me. That
is a character and integrity hit you do not want. But you live as
you like.


Not intending to be insulting at all, but as your first paragraph
suggests, you've probably never done what I'm attempting to describe.
(Or perhaps I just didn't describe it well enough initially.)

I have experienced that. It works when a team of engineers is assigned to a product/product line and they trust each other and the company is not in a layoff cycle. In other words, it is rare. My persecution (and experience at the moment) is that companies are doing the matrix form of running projects.

In the matrix org people are replaceable and even the project managers are replaceable. Good team interaction is not budgeted into the schedule and it does not occur. My company at the moment is doing a project with input from 5 sites. It is going better than I expect, but it is not nearly as satisfying as working in a project structure. Also, it is sort of working because the majority of engineers are very experienced and are not falling into the matrix structures pitfalls. Heaven help a company when they assign significant responsibility to younger engineers in a matrix org.




Cheers

Phil Hobbs

(*) The use of helicopter propwash to knock ice off high-tension wires
allegedly came out of a discussion like that.

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com
 

Welcome to EDABoard.com

Sponsor

Back
Top