Maximum Power Point Tracking: Optimizing Solar Panels 58 Comments by: Maya Posch...

[Phil Hobbs]

Joerg wrote:

On 1/10/23 8:22 AM, Phil Hobbs wrote:
Phil Hobbs wrote:
Joerg wrote:
On 1/2/23 5:57 PM, Phil Hobbs wrote:
John Larkin wrote:
On Mon, 2 Jan 2023 11:00:52 -0800, Joerg <news@analogconsultants.com
wrote:

On 1/1/23 11:08 PM, Jan Panteltje wrote:

[...]

In the EE school I was in it was known that only \'hobbyists\'
would pass the final exams. The dropout in the first year was
very very very high.


At my university the drop-out rate (start to degree) was at times
83%.

Too many kids selected an EE degree based on some high school
counselor\'s advice, or dreams of a tidy income. Too late.

I dunno.  Washing out of a hard program isn\'t the worst thing that can
happen to a young person.  It\'s not nearly as bad as hanging on by the
skin of your teeth and then failing over a decade or so in the
industry.

The old saying, \"C\'s get degrees\" has caused a lot of misery of
that sort.


I had pretty bad grades because I worked a lot on the side, did
\"pre-degree consulting\" and stuff like that. Bad grades are ok.

In an honest system, bad grades mean that the student either didn\'t
do the work, or was unable or unwilling to do it well.  There can be
lots of reasons for that, such as being unavoidably too busy, but
that\'s not the usual case.

The result is wasted time and money, and usually a skill set that\'s
full of holes and harder to build on later.  It sounds like you were
sort of making up your own enrichment curriculum as you went on,
which is a bit different, of course.


I really lost interest in attending university lectures after a few
things were taught by professors that were profoundly wrong. The first
one was that RF transmitters must have an output impedance equal to the
impedance of the connected load or cable. The week after I brought in
the schematic of a then-modern transistorized ham radio transceiver and
pointed out the final amplifier. The professor didn\'t really know what
to say.

Number two: The same guy said that grounded gate circuits in RF stages
make no sense at all. Huh? I did one of those during my very first job
assignment when the ink on my degree was barely dry. And lots before as
a hobbyist.

Number three: Another professor said that we only need to learn all this
transistor-level stuff for the exam. Once we graduated this would all be
obsoleted by integrated circuits. That one took the cake. Still, it
seemed I was the only one who didn\'t believe such nonsense. However, it
provided me with the epiphany \"Ha! This is my niche!\". And that\'s what
it became. Never looked back.

This was at a European ivy league place which made it even more
disappointing.

Well, I\'ve never taken a circuits class, so I may have dodged a bullet
or two of that sort. (*)

I don\'t recall ever being told what would or would not be important in
my future career, but maybe I just didn\'t listen.

I knew some very smart folks whose grades were poor, but they were
mostly unmotivated or undisciplined.  One guy (a math genius) was in
my grad school study group for awhile, but was way too handsome for
his own good--he spent his time playing soccer and chasing women, and
tried to skate by on talent as he\'d always done.  Eventually it
stopped working. If you go far enough, it always does.


My dad hinted that I was a bread scholar who\'d only learn something if
it can be put to profitable use, and prontissimo. For the most part he
was right.



That\'s the real benefit of weed-out courses--not that many people
flunk, but that the ones who succeed have to learn to learn mental
discipline in the process.  That\'ll stand you in good stead for a
lifetime. (Flunking isn\'t the worst thing that can happen to you. I
got fired from my first job, which was very beneficial overall.)



Agree, it makes the students tough. Just like military service does.
When I was at boot camp I really resented being in the Army, life was
hard, sergeants screaming in our faces, and so on. Later in life I
realized that it had taught me a lot that I use to this day.


Students sometimes ask me for advice, and I always tell them three
things: first, in every field, make sure you have the fundamentals
down cold; second, concentrate your course work on things that are
hard to pick up on your own, especially math; and third, join a
research group where you can do a lot of stuff on your own.  (The
ideal is to have an interesting smallish project, where you have to
do everything, and a bunch of smart and supportive colleagues.)

That\'s the most direct path to wizardhood that I know about.


I think a job is very educational. In Germany we had to do a minimum of
six months of \"relevant industrial practice\" for a masters degree. Sort
of internships, during our studies. Three of those months had to be
completed by the 4th semester. It could not be all at one place but
AFAIR at four companies. The jobs had to be meticulously documented.
These documents had to be turned in and the university had to approve
them or it wouldn\'t count. Not always easy. Two of mine were in a
foreign language (to them) and they gave me some grief about that.

They did away with that requirement which I think was a major mistake.

Sounds super cumbersome. I can\'t imagine getting the sort of industry
buy-in that that would require. I knew a fair number of EE co-op
students at grad school, both from business and from the military, and
the DSP course had a live video feed to some companies\' sites, which was
fairly novel in 1985. (They were mostly defence contractors IIRC.)

I did some other bigger jobs also and at some point was a taxpayer in
three different countries. That alone is a teachable situation.

Yikes.

Another upside of this is that you don\'t finish university with a chunk
of student debt but with savings in the bank.

Because I started university youngish, I had time to do a gap year and
then worked for a couple of years at a local telecoms place (Microtel)
where they really chucked me in the deep end. Very educational indeed.

(*) I did take the required \"RLC for physicists\" class as a sophomore,
which talked about resonance, damping factors and so on.

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]

Joerg wrote:

On 1/10/23 8:22 AM, Phil Hobbs wrote:
Phil Hobbs wrote:
Joerg wrote:
On 1/2/23 5:57 PM, Phil Hobbs wrote:
John Larkin wrote:
On Mon, 2 Jan 2023 11:00:52 -0800, Joerg <news@analogconsultants.com
wrote:

On 1/1/23 11:08 PM, Jan Panteltje wrote:

[...]

In the EE school I was in it was known that only \'hobbyists\'
would pass the final exams. The dropout in the first year was
very very very high.


At my university the drop-out rate (start to degree) was at times
83%.

Too many kids selected an EE degree based on some high school
counselor\'s advice, or dreams of a tidy income. Too late.

I dunno.  Washing out of a hard program isn\'t the worst thing that can
happen to a young person.  It\'s not nearly as bad as hanging on by the
skin of your teeth and then failing over a decade or so in the
industry.

The old saying, \"C\'s get degrees\" has caused a lot of misery of
that sort.


I had pretty bad grades because I worked a lot on the side, did
\"pre-degree consulting\" and stuff like that. Bad grades are ok.

In an honest system, bad grades mean that the student either didn\'t
do the work, or was unable or unwilling to do it well.  There can be
lots of reasons for that, such as being unavoidably too busy, but
that\'s not the usual case.

The result is wasted time and money, and usually a skill set that\'s
full of holes and harder to build on later.  It sounds like you were
sort of making up your own enrichment curriculum as you went on,
which is a bit different, of course.


I really lost interest in attending university lectures after a few
things were taught by professors that were profoundly wrong. The first
one was that RF transmitters must have an output impedance equal to the
impedance of the connected load or cable. The week after I brought in
the schematic of a then-modern transistorized ham radio transceiver and
pointed out the final amplifier. The professor didn\'t really know what
to say.

Number two: The same guy said that grounded gate circuits in RF stages
make no sense at all. Huh? I did one of those during my very first job
assignment when the ink on my degree was barely dry. And lots before as
a hobbyist.

Number three: Another professor said that we only need to learn all this
transistor-level stuff for the exam. Once we graduated this would all be
obsoleted by integrated circuits. That one took the cake. Still, it
seemed I was the only one who didn\'t believe such nonsense. However, it
provided me with the epiphany \"Ha! This is my niche!\". And that\'s what
it became. Never looked back.

This was at a European ivy league place which made it even more
disappointing.

Well, I\'ve never taken a circuits class, so I may have dodged a bullet
or two of that sort. (*)

I don\'t recall ever being told what would or would not be important in
my future career, but maybe I just didn\'t listen.

I knew some very smart folks whose grades were poor, but they were
mostly unmotivated or undisciplined.  One guy (a math genius) was in
my grad school study group for awhile, but was way too handsome for
his own good--he spent his time playing soccer and chasing women, and
tried to skate by on talent as he\'d always done.  Eventually it
stopped working. If you go far enough, it always does.


My dad hinted that I was a bread scholar who\'d only learn something if
it can be put to profitable use, and prontissimo. For the most part he
was right.



That\'s the real benefit of weed-out courses--not that many people
flunk, but that the ones who succeed have to learn to learn mental
discipline in the process.  That\'ll stand you in good stead for a
lifetime. (Flunking isn\'t the worst thing that can happen to you. I
got fired from my first job, which was very beneficial overall.)



Agree, it makes the students tough. Just like military service does.
When I was at boot camp I really resented being in the Army, life was
hard, sergeants screaming in our faces, and so on. Later in life I
realized that it had taught me a lot that I use to this day.


Students sometimes ask me for advice, and I always tell them three
things: first, in every field, make sure you have the fundamentals
down cold; second, concentrate your course work on things that are
hard to pick up on your own, especially math; and third, join a
research group where you can do a lot of stuff on your own.  (The
ideal is to have an interesting smallish project, where you have to
do everything, and a bunch of smart and supportive colleagues.)

That\'s the most direct path to wizardhood that I know about.


I think a job is very educational. In Germany we had to do a minimum of
six months of \"relevant industrial practice\" for a masters degree. Sort
of internships, during our studies. Three of those months had to be
completed by the 4th semester. It could not be all at one place but
AFAIR at four companies. The jobs had to be meticulously documented.
These documents had to be turned in and the university had to approve
them or it wouldn\'t count. Not always easy. Two of mine were in a
foreign language (to them) and they gave me some grief about that.

They did away with that requirement which I think was a major mistake.

Sounds super cumbersome. I can\'t imagine getting the sort of industry
buy-in that that would require. I knew a fair number of EE co-op
students at grad school, both from business and from the military, and
the DSP course had a live video feed to some companies\' sites, which was
fairly novel in 1985. (They were mostly defence contractors IIRC.)

I did some other bigger jobs also and at some point was a taxpayer in
three different countries. That alone is a teachable situation.

Yikes.

Another upside of this is that you don\'t finish university with a chunk
of student debt but with savings in the bank.

Because I started university youngish, I had time to do a gap year and
then worked for a couple of years at a local telecoms place (Microtel)
where they really chucked me in the deep end. Very educational indeed.

(*) I did take the required \"RLC for physicists\" class as a sophomore,
which talked about resonance, damping factors and so on.

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]

Joerg wrote:

On 1/10/23 8:22 AM, Phil Hobbs wrote:
Phil Hobbs wrote:
Joerg wrote:
On 1/2/23 5:57 PM, Phil Hobbs wrote:
John Larkin wrote:
On Mon, 2 Jan 2023 11:00:52 -0800, Joerg <news@analogconsultants.com
wrote:

On 1/1/23 11:08 PM, Jan Panteltje wrote:

[...]

In the EE school I was in it was known that only \'hobbyists\'
would pass the final exams. The dropout in the first year was
very very very high.


At my university the drop-out rate (start to degree) was at times
83%.

Too many kids selected an EE degree based on some high school
counselor\'s advice, or dreams of a tidy income. Too late.

I dunno.  Washing out of a hard program isn\'t the worst thing that can
happen to a young person.  It\'s not nearly as bad as hanging on by the
skin of your teeth and then failing over a decade or so in the
industry.

The old saying, \"C\'s get degrees\" has caused a lot of misery of
that sort.


I had pretty bad grades because I worked a lot on the side, did
\"pre-degree consulting\" and stuff like that. Bad grades are ok.

In an honest system, bad grades mean that the student either didn\'t
do the work, or was unable or unwilling to do it well.  There can be
lots of reasons for that, such as being unavoidably too busy, but
that\'s not the usual case.

The result is wasted time and money, and usually a skill set that\'s
full of holes and harder to build on later.  It sounds like you were
sort of making up your own enrichment curriculum as you went on,
which is a bit different, of course.


I really lost interest in attending university lectures after a few
things were taught by professors that were profoundly wrong. The first
one was that RF transmitters must have an output impedance equal to the
impedance of the connected load or cable. The week after I brought in
the schematic of a then-modern transistorized ham radio transceiver and
pointed out the final amplifier. The professor didn\'t really know what
to say.

Number two: The same guy said that grounded gate circuits in RF stages
make no sense at all. Huh? I did one of those during my very first job
assignment when the ink on my degree was barely dry. And lots before as
a hobbyist.

Number three: Another professor said that we only need to learn all this
transistor-level stuff for the exam. Once we graduated this would all be
obsoleted by integrated circuits. That one took the cake. Still, it
seemed I was the only one who didn\'t believe such nonsense. However, it
provided me with the epiphany \"Ha! This is my niche!\". And that\'s what
it became. Never looked back.

This was at a European ivy league place which made it even more
disappointing.

Well, I\'ve never taken a circuits class, so I may have dodged a bullet
or two of that sort. (*)

I don\'t recall ever being told what would or would not be important in
my future career, but maybe I just didn\'t listen.

I knew some very smart folks whose grades were poor, but they were
mostly unmotivated or undisciplined.  One guy (a math genius) was in
my grad school study group for awhile, but was way too handsome for
his own good--he spent his time playing soccer and chasing women, and
tried to skate by on talent as he\'d always done.  Eventually it
stopped working. If you go far enough, it always does.


My dad hinted that I was a bread scholar who\'d only learn something if
it can be put to profitable use, and prontissimo. For the most part he
was right.



That\'s the real benefit of weed-out courses--not that many people
flunk, but that the ones who succeed have to learn to learn mental
discipline in the process.  That\'ll stand you in good stead for a
lifetime. (Flunking isn\'t the worst thing that can happen to you. I
got fired from my first job, which was very beneficial overall.)



Agree, it makes the students tough. Just like military service does.
When I was at boot camp I really resented being in the Army, life was
hard, sergeants screaming in our faces, and so on. Later in life I
realized that it had taught me a lot that I use to this day.


Students sometimes ask me for advice, and I always tell them three
things: first, in every field, make sure you have the fundamentals
down cold; second, concentrate your course work on things that are
hard to pick up on your own, especially math; and third, join a
research group where you can do a lot of stuff on your own.  (The
ideal is to have an interesting smallish project, where you have to
do everything, and a bunch of smart and supportive colleagues.)

That\'s the most direct path to wizardhood that I know about.


I think a job is very educational. In Germany we had to do a minimum of
six months of \"relevant industrial practice\" for a masters degree. Sort
of internships, during our studies. Three of those months had to be
completed by the 4th semester. It could not be all at one place but
AFAIR at four companies. The jobs had to be meticulously documented.
These documents had to be turned in and the university had to approve
them or it wouldn\'t count. Not always easy. Two of mine were in a
foreign language (to them) and they gave me some grief about that.

They did away with that requirement which I think was a major mistake.

Sounds super cumbersome. I can\'t imagine getting the sort of industry
buy-in that that would require. I knew a fair number of EE co-op
students at grad school, both from business and from the military, and
the DSP course had a live video feed to some companies\' sites, which was
fairly novel in 1985. (They were mostly defence contractors IIRC.)

I did some other bigger jobs also and at some point was a taxpayer in
three different countries. That alone is a teachable situation.

Yikes.

Another upside of this is that you don\'t finish university with a chunk
of student debt but with savings in the bank.

Because I started university youngish, I had time to do a gap year and
then worked for a couple of years at a local telecoms place (Microtel)
where they really chucked me in the deep end. Very educational indeed.

(*) I did take the required \"RLC for physicists\" class as a sophomore,
which talked about resonance, damping factors and so on.

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

 

[Lamont Cranston]

On Tuesday, January 3, 2023 at 12:31:13 AM UTC-6, Jan Panteltje wrote:

Indeed, like analog video 1 Vpp
You lose your black level...
OTOH a diode after the RC will fix that for video (clamp the negative sync pulse at some fixed level).
It all depends...

From 48 years ago, vidicon cameras for factory surveillance , car headlights would wash out the picture.
One of the guys made a circuit that that clamped any high level white (headlights) to zero (black).
Worked great, the cars just had two black blobs on the front, and the picture didn\'t wash out.
Mikek

 

[Lamont Cranston]

On Tuesday, January 3, 2023 at 12:31:13 AM UTC-6, Jan Panteltje wrote:

Indeed, like analog video 1 Vpp
You lose your black level...
OTOH a diode after the RC will fix that for video (clamp the negative sync pulse at some fixed level).
It all depends...

From 48 years ago, vidicon cameras for factory surveillance , car headlights would wash out the picture.
One of the guys made a circuit that that clamped any high level white (headlights) to zero (black).
Worked great, the cars just had two black blobs on the front, and the picture didn\'t wash out.
Mikek

 

[Lamont Cranston]

On Tuesday, January 3, 2023 at 12:31:13 AM UTC-6, Jan Panteltje wrote:

Indeed, like analog video 1 Vpp
You lose your black level...
OTOH a diode after the RC will fix that for video (clamp the negative sync pulse at some fixed level).
It all depends...

From 48 years ago, vidicon cameras for factory surveillance , car headlights would wash out the picture.
One of the guys made a circuit that that clamped any high level white (headlights) to zero (black).
Worked great, the cars just had two black blobs on the front, and the picture didn\'t wash out.
Mikek

 

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2023-01-04, legg wrote:

[...]
Also called into another business to \'break in\' a new production
line tester/troubleshooter. He didn\'t know what the color code was.
I guess he knows it now. Local tech school graduate of recent import.

I\'m assuming you mean the telecoms colors for binder groups? Or was it
something else?


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmO1mhoACgkQbWVw5Uzn
KGD/jhAArQt0CEKhB59KxjpZOqlOh4zoSVE2f6V4dPKaObOZv4nOFmHagn+6KvhA
fkXqjBEhY1Fhp/zNuCb5bBj3ZFP/DxMM0LkjWQCvfROIZZRy8fZamzl/pyNCwoDt
NyzjC5JGicuEB6R4vdQlGPrJh/vHH91yyhbO49p0mOM9Ah77iZk8G/LQrorsSdL6
XQj/L4Gy7FIQxbZyaDF6ROQhh6FIi9EyGn7SZrF9CHBs9jfdBIlMkIKUpQPZzhr5
NTs+V4madZi80OV46pY2boAd4rhKQrtsBi6KoPLgJWU7zBXU1Z8+arG4gYt+EA7W
iAe6Cj6XfOvz3jVTkDxjLPBgtwVKej+IHGCEJhuxXwfSDRip6grOiivtWtqsK0Ru
MJpXXIgiKw6bQ2C1lFHz1/TgKtCp+1VZiVdRKUAMyQvlPX/pLvPIkcndTk10Ea+2
WKOm0KDONL2gRibQHf0/d7DrZClGPzi9g0EAtAcWVEA3Qd5C32QJ1UEVZ2tthchA
JedDWLsIRJpB+OXKhvgzZQ/JVFratjxPieraMkCPxSAK3mmM2y5krn8eYc1v8Goh
PHrYsNoJqD0E97ZMmnj/C8ApPSw2MGvp/JiWTU6aQ6Dseu+xLJe6m1hq9umNQE56
TGmwN4tD5I1b7nvwvikGBxpDKftGeTM39YwABP8heAtZbRFz6o8=
=ytPu
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

 

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2023-01-04, legg wrote:

[...]
Also called into another business to \'break in\' a new production
line tester/troubleshooter. He didn\'t know what the color code was.
I guess he knows it now. Local tech school graduate of recent import.

I\'m assuming you mean the telecoms colors for binder groups? Or was it
something else?


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmO1mhoACgkQbWVw5Uzn
KGD/jhAArQt0CEKhB59KxjpZOqlOh4zoSVE2f6V4dPKaObOZv4nOFmHagn+6KvhA
fkXqjBEhY1Fhp/zNuCb5bBj3ZFP/DxMM0LkjWQCvfROIZZRy8fZamzl/pyNCwoDt
NyzjC5JGicuEB6R4vdQlGPrJh/vHH91yyhbO49p0mOM9Ah77iZk8G/LQrorsSdL6
XQj/L4Gy7FIQxbZyaDF6ROQhh6FIi9EyGn7SZrF9CHBs9jfdBIlMkIKUpQPZzhr5
NTs+V4madZi80OV46pY2boAd4rhKQrtsBi6KoPLgJWU7zBXU1Z8+arG4gYt+EA7W
iAe6Cj6XfOvz3jVTkDxjLPBgtwVKej+IHGCEJhuxXwfSDRip6grOiivtWtqsK0Ru
MJpXXIgiKw6bQ2C1lFHz1/TgKtCp+1VZiVdRKUAMyQvlPX/pLvPIkcndTk10Ea+2
WKOm0KDONL2gRibQHf0/d7DrZClGPzi9g0EAtAcWVEA3Qd5C32QJ1UEVZ2tthchA
JedDWLsIRJpB+OXKhvgzZQ/JVFratjxPieraMkCPxSAK3mmM2y5krn8eYc1v8Goh
PHrYsNoJqD0E97ZMmnj/C8ApPSw2MGvp/JiWTU6aQ6Dseu+xLJe6m1hq9umNQE56
TGmwN4tD5I1b7nvwvikGBxpDKftGeTM39YwABP8heAtZbRFz6o8=
=ytPu
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

 

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2023-01-04, legg wrote:

[...]
Also called into another business to \'break in\' a new production
line tester/troubleshooter. He didn\'t know what the color code was.
I guess he knows it now. Local tech school graduate of recent import.

I\'m assuming you mean the telecoms colors for binder groups? Or was it
something else?


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmO1mhoACgkQbWVw5Uzn
KGD/jhAArQt0CEKhB59KxjpZOqlOh4zoSVE2f6V4dPKaObOZv4nOFmHagn+6KvhA
fkXqjBEhY1Fhp/zNuCb5bBj3ZFP/DxMM0LkjWQCvfROIZZRy8fZamzl/pyNCwoDt
NyzjC5JGicuEB6R4vdQlGPrJh/vHH91yyhbO49p0mOM9Ah77iZk8G/LQrorsSdL6
XQj/L4Gy7FIQxbZyaDF6ROQhh6FIi9EyGn7SZrF9CHBs9jfdBIlMkIKUpQPZzhr5
NTs+V4madZi80OV46pY2boAd4rhKQrtsBi6KoPLgJWU7zBXU1Z8+arG4gYt+EA7W
iAe6Cj6XfOvz3jVTkDxjLPBgtwVKej+IHGCEJhuxXwfSDRip6grOiivtWtqsK0Ru
MJpXXIgiKw6bQ2C1lFHz1/TgKtCp+1VZiVdRKUAMyQvlPX/pLvPIkcndTk10Ea+2
WKOm0KDONL2gRibQHf0/d7DrZClGPzi9g0EAtAcWVEA3Qd5C32QJ1UEVZ2tthchA
JedDWLsIRJpB+OXKhvgzZQ/JVFratjxPieraMkCPxSAK3mmM2y5krn8eYc1v8Goh
PHrYsNoJqD0E97ZMmnj/C8ApPSw2MGvp/JiWTU6aQ6Dseu+xLJe6m1hq9umNQE56
TGmwN4tD5I1b7nvwvikGBxpDKftGeTM39YwABP8heAtZbRFz6o8=
=ytPu
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

 

[Don Y]

On 1/9/2023 12:35 PM, whit3rd wrote:

Oh, but the people I worked with were NOT careful. One coworker rewrote
a function from the main library, but didn\'t give his variant a different name. Big
oops if you didn\'t know exactly what order to offer the libraries to the linker.
Another coworker decided his filenames would never exceed 72 characters,
and when (disk/directory/subdirectory/name combined) added up
to 73 characters for a particular subdirectory, programs that worked inputting from
user9 directory failed for user10 directory.

Neither coworker was open to change.

I worked with a guy who was constantly REbugging the floating point library.
You\'d wonder why YOUR code was suddenly not working -- only to discover,
in a misguided attempt to squeeze a few more cycles out of the FP library,
that he\'d BROKEN it, YET AGAIN!

Good practices require discipline. For a large firm, you can secure
the repository and install practices that ensure folks can\'t check-in
new releases without following a procedure (that includes having
test suites in place, etc.). For smaller firms, you rely on the
individual developers to SELF-discipline.

Should I have to review EVERY piece of code that I drag into
my build, just to verify that it works? What\'s the point of having
\"software assemblies\" if there are no guarantees in place that they
are correct? (Do you test every hardware component before securing
it to a PCB?)

What\'s worse is most firms can\'t tell you the state of their
repositories; they rely on their workers for that. \"Yeah,
the floating point library works.\" \"Really? Who told you THAT?\"

 

[Don Y]

On 1/9/2023 12:35 PM, whit3rd wrote:

Oh, but the people I worked with were NOT careful. One coworker rewrote
a function from the main library, but didn\'t give his variant a different name. Big
oops if you didn\'t know exactly what order to offer the libraries to the linker.
Another coworker decided his filenames would never exceed 72 characters,
and when (disk/directory/subdirectory/name combined) added up
to 73 characters for a particular subdirectory, programs that worked inputting from
user9 directory failed for user10 directory.

Neither coworker was open to change.

I worked with a guy who was constantly REbugging the floating point library.
You\'d wonder why YOUR code was suddenly not working -- only to discover,
in a misguided attempt to squeeze a few more cycles out of the FP library,
that he\'d BROKEN it, YET AGAIN!

Good practices require discipline. For a large firm, you can secure
the repository and install practices that ensure folks can\'t check-in
new releases without following a procedure (that includes having
test suites in place, etc.). For smaller firms, you rely on the
individual developers to SELF-discipline.

Should I have to review EVERY piece of code that I drag into
my build, just to verify that it works? What\'s the point of having
\"software assemblies\" if there are no guarantees in place that they
are correct? (Do you test every hardware component before securing
it to a PCB?)

What\'s worse is most firms can\'t tell you the state of their
repositories; they rely on their workers for that. \"Yeah,
the floating point library works.\" \"Really? Who told you THAT?\"

 

[Don Y]

On 1/9/2023 12:35 PM, whit3rd wrote:

Oh, but the people I worked with were NOT careful. One coworker rewrote
a function from the main library, but didn\'t give his variant a different name. Big
oops if you didn\'t know exactly what order to offer the libraries to the linker.
Another coworker decided his filenames would never exceed 72 characters,
and when (disk/directory/subdirectory/name combined) added up
to 73 characters for a particular subdirectory, programs that worked inputting from
user9 directory failed for user10 directory.

Neither coworker was open to change.

I worked with a guy who was constantly REbugging the floating point library.
You\'d wonder why YOUR code was suddenly not working -- only to discover,
in a misguided attempt to squeeze a few more cycles out of the FP library,
that he\'d BROKEN it, YET AGAIN!

Good practices require discipline. For a large firm, you can secure
the repository and install practices that ensure folks can\'t check-in
new releases without following a procedure (that includes having
test suites in place, etc.). For smaller firms, you rely on the
individual developers to SELF-discipline.

Should I have to review EVERY piece of code that I drag into
my build, just to verify that it works? What\'s the point of having
\"software assemblies\" if there are no guarantees in place that they
are correct? (Do you test every hardware component before securing
it to a PCB?)

What\'s worse is most firms can\'t tell you the state of their
repositories; they rely on their workers for that. \"Yeah,
the floating point library works.\" \"Really? Who told you THAT?\"

 

[Anthony William Sloman]

On Wednesday, January 4, 2023 at 4:45:21 PM UTC+11, Jan Panteltje wrote:

On a sunny day (Tue, 3 Jan 2023 18:37:33 -0800 (PST)) it happened Anthony
William Sloman <bill....@ieee.org> wrote in
1c552bd5-dddd-48cd...@googlegroups.com>:
I did read Al Gore\'s book - \"Earth in the Balance\"

I knew it!!!

You seem to have snipped the rest of my response.

\"but long after it was first published. The polar bear story come from the film \"An Inconvenient Truth\" which I\'ve never seen.

The famous UK climate change denial shill - Viscount Monckton - made a great fuss about the polar bears, and it has been a climate change denial staple ever since. Your enthusiasm for it shows where you get your misinformation.\"

Your enthusiasm for self-congratulation does seem to have run away with you. I read the book - which was published in 1992 - some ten years later, mainly to see how well it stood up. It did pretty well - Al Gore seems to have got good advice from people who knew what they were talking about (which you don\'t).

--
Bill Sloman, Sydney

 

[Anthony William Sloman]

On Wednesday, January 4, 2023 at 4:45:21 PM UTC+11, Jan Panteltje wrote:

On a sunny day (Tue, 3 Jan 2023 18:37:33 -0800 (PST)) it happened Anthony
William Sloman <bill....@ieee.org> wrote in
1c552bd5-dddd-48cd...@googlegroups.com>:
I did read Al Gore\'s book - \"Earth in the Balance\"

I knew it!!!

You seem to have snipped the rest of my response.

\"but long after it was first published. The polar bear story come from the film \"An Inconvenient Truth\" which I\'ve never seen.

The famous UK climate change denial shill - Viscount Monckton - made a great fuss about the polar bears, and it has been a climate change denial staple ever since. Your enthusiasm for it shows where you get your misinformation.\"

Your enthusiasm for self-congratulation does seem to have run away with you. I read the book - which was published in 1992 - some ten years later, mainly to see how well it stood up. It did pretty well - Al Gore seems to have got good advice from people who knew what they were talking about (which you don\'t).

--
Bill Sloman, Sydney

 

[Anthony William Sloman]

On Wednesday, January 4, 2023 at 4:45:21 PM UTC+11, Jan Panteltje wrote:

On a sunny day (Tue, 3 Jan 2023 18:37:33 -0800 (PST)) it happened Anthony
William Sloman <bill....@ieee.org> wrote in
1c552bd5-dddd-48cd...@googlegroups.com>:
I did read Al Gore\'s book - \"Earth in the Balance\"

I knew it!!!

You seem to have snipped the rest of my response.

\"but long after it was first published. The polar bear story come from the film \"An Inconvenient Truth\" which I\'ve never seen.

The famous UK climate change denial shill - Viscount Monckton - made a great fuss about the polar bears, and it has been a climate change denial staple ever since. Your enthusiasm for it shows where you get your misinformation.\"

Your enthusiasm for self-congratulation does seem to have run away with you. I read the book - which was published in 1992 - some ten years later, mainly to see how well it stood up. It did pretty well - Al Gore seems to have got good advice from people who knew what they were talking about (which you don\'t).

--
Bill Sloman, Sydney

 

[Don Y]

On 1/7/2023 4:11 PM, Joe Gwinn wrote:

Things which do have an important place in modern software that is
intended to be provably correct are invariants (borrowed from physics).

Yes, but if I recall we called them Assertions:

.<https://en.wikipedia.org/wiki/Assertion_(software_development)

Software also has Invariants, but I don\'t know that either one came
from the Physics world.

.<https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invariants_in_computer_science

The main difference in software seems to be that assertions are
logical statements about the value of a single variable, while
Invariants apply an assertion to the result of a specified function.

One kind of assertion was visual - coplot a 2D plot of something, plus
a circle, and visually verify concentricity. The eye is _very_ good
at this, so it was a very robust and sensitive test.

I for one used them heavily, with some being used in operation, not
just development. This was done in runtime code, not as a property of
the programming language and/or compiler.

That, and the fact that many languages simply don\'t natively support
them, means they end up being a matter of \"discipline\" and not
really enforceable (design reviews?).

I, for example, support the specification of invariant in-out conditions
in my IDL. I feel this makes the contract more explicit -- in terms
that the developer WILL see (and, that the auto-generated stubs will
enforce in case he wants to overlook them! :> ).

But, I can\'t mechanically require the designer of an object class
(or service) to define them meaningfully.

And, what do you do when one fails at runtime? How often does
code simply propagate assertions up to a top level handler...
that panic()\'s?

More significantly, do you see real-time software implementing
invariants wrt deadlines? (oops! isn\'t that the whole point of RT??)
Again, I support the specification of per-task \"deadline handlers\"
but there\'s nothing that forces the developer to define one meaningfully.

When folks are still failing to test the results of many common
functions (malloc() being a prime example... but, how often have
you tested the return value of printf()?), how can you expect
them to have sorted out what to do for each thrown exception,
failed invariant, etc.?

Finally, as they are never supposed to execute, some industries
dictate that they be removed from production code, classifying
them as \"dead code\" (they aren\'t supposed to have side-effects).

Would you have an argument for leaving this in your code?
if (FALSE) panic();
Isn\'t that what an invariant *effectively* reduces to?

 

[Don Y]

On 1/7/2023 4:11 PM, Joe Gwinn wrote:

Things which do have an important place in modern software that is
intended to be provably correct are invariants (borrowed from physics).

Yes, but if I recall we called them Assertions:

.<https://en.wikipedia.org/wiki/Assertion_(software_development)

Software also has Invariants, but I don\'t know that either one came
from the Physics world.

.<https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invariants_in_computer_science

The main difference in software seems to be that assertions are
logical statements about the value of a single variable, while
Invariants apply an assertion to the result of a specified function.

One kind of assertion was visual - coplot a 2D plot of something, plus
a circle, and visually verify concentricity. The eye is _very_ good
at this, so it was a very robust and sensitive test.

I for one used them heavily, with some being used in operation, not
just development. This was done in runtime code, not as a property of
the programming language and/or compiler.

That, and the fact that many languages simply don\'t natively support
them, means they end up being a matter of \"discipline\" and not
really enforceable (design reviews?).

I, for example, support the specification of invariant in-out conditions
in my IDL. I feel this makes the contract more explicit -- in terms
that the developer WILL see (and, that the auto-generated stubs will
enforce in case he wants to overlook them! :> ).

But, I can\'t mechanically require the designer of an object class
(or service) to define them meaningfully.

And, what do you do when one fails at runtime? How often does
code simply propagate assertions up to a top level handler...
that panic()\'s?

More significantly, do you see real-time software implementing
invariants wrt deadlines? (oops! isn\'t that the whole point of RT??)
Again, I support the specification of per-task \"deadline handlers\"
but there\'s nothing that forces the developer to define one meaningfully.

When folks are still failing to test the results of many common
functions (malloc() being a prime example... but, how often have
you tested the return value of printf()?), how can you expect
them to have sorted out what to do for each thrown exception,
failed invariant, etc.?

Finally, as they are never supposed to execute, some industries
dictate that they be removed from production code, classifying
them as \"dead code\" (they aren\'t supposed to have side-effects).

Would you have an argument for leaving this in your code?
if (FALSE) panic();
Isn\'t that what an invariant *effectively* reduces to?

 

[Don Y]

On 1/7/2023 4:11 PM, Joe Gwinn wrote:

Things which do have an important place in modern software that is
intended to be provably correct are invariants (borrowed from physics).

Yes, but if I recall we called them Assertions:

.<https://en.wikipedia.org/wiki/Assertion_(software_development)

Software also has Invariants, but I don\'t know that either one came
from the Physics world.

.<https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invariants_in_computer_science

The main difference in software seems to be that assertions are
logical statements about the value of a single variable, while
Invariants apply an assertion to the result of a specified function.

One kind of assertion was visual - coplot a 2D plot of something, plus
a circle, and visually verify concentricity. The eye is _very_ good
at this, so it was a very robust and sensitive test.

I for one used them heavily, with some being used in operation, not
just development. This was done in runtime code, not as a property of
the programming language and/or compiler.

That, and the fact that many languages simply don\'t natively support
them, means they end up being a matter of \"discipline\" and not
really enforceable (design reviews?).

I, for example, support the specification of invariant in-out conditions
in my IDL. I feel this makes the contract more explicit -- in terms
that the developer WILL see (and, that the auto-generated stubs will
enforce in case he wants to overlook them! :> ).

But, I can\'t mechanically require the designer of an object class
(or service) to define them meaningfully.

And, what do you do when one fails at runtime? How often does
code simply propagate assertions up to a top level handler...
that panic()\'s?

More significantly, do you see real-time software implementing
invariants wrt deadlines? (oops! isn\'t that the whole point of RT??)
Again, I support the specification of per-task \"deadline handlers\"
but there\'s nothing that forces the developer to define one meaningfully.

When folks are still failing to test the results of many common
functions (malloc() being a prime example... but, how often have
you tested the return value of printf()?), how can you expect
them to have sorted out what to do for each thrown exception,
failed invariant, etc.?

Finally, as they are never supposed to execute, some industries
dictate that they be removed from production code, classifying
them as \"dead code\" (they aren\'t supposed to have side-effects).

Would you have an argument for leaving this in your code?
if (FALSE) panic();
Isn\'t that what an invariant *effectively* reduces to?

 

[Joe Gwinn]

On Wed, 4 Jan 2023 16:08:37 +0000, Martin Brown
<\'\'\'newspam\'\'\'@nonad.co.uk> wrote:

On 04/01/2023 14:54, bitrex wrote:
On 1/4/2023 9:52 AM, bitrex wrote:
On 1/3/2023 7:30 PM, Phil Hobbs wrote:

I agree that knowing the fundamentals cold is very important.
However, (a) physics isn\'t for everyone, by a long chalk; and (b)
there\'s a glorious intellectual heritage in engineering, so calling
it \'vocational training\' is pejorative.

Cheers

Phil \"Intermediate energy state\" Hobbs


Advanced engineering mathematics:

https://www.ebay.com/itm/194964206310

Which is pretty advanced, I don\'t know how many BS-type EEs know about
the orthogonality of Bessel functions, or regularly use contour
integration for anything.

I once used contour integration to obtain a fringe field correction on a
mass spectrometer magnet. The objective was to take out the first order
aberrations and make the focal plane orthogonal to the optic axis.

It was one of the first electromagnetic optics codes where the magnitude
of the predicted voltages on electrodes was sometime right. Prior to
that you were lucky if it had the right sign! The original code came off
a mainframe and was intended for designing atom smashers. A listing
arrived at the company from academia with my new boss.

Physics was mainly into Chebyshev polynomials for solving wavefunction
equations since it housed one of the world experts in the field.

But not as advanced as \"Advanced Mathematical Methods for Scientists &
Engineers\", which is largely about perturbation methods, boundary
layer theory, and WKB approximations. Sounds fun I guess, I just got a
used copy from Amazon for $8

I would expect stuff like the WKB approximation is regularly used more
in optics design than in circuit design, though.

A bit like Green\'s function I\'m inclined to think that WKB is seldom
used at all now that we have very fast raytracers on the desktop PC. It
may still be taught at undergraduate level today but mainly to weed out
those that are not going to make it as a theoretical physicist (which is
where it was used back in my day as an undergraduate).

Padé rational approximation methods are undergoing something of a
Renaissance. Things go in cycles. I keep waiting for Clifford Algebras
to take off as my supervisor promised they soon would (~2 decades ago).

Things which do have an important place in modern software that is
intended to be provably correct are invariants (borrowed from physics).

Yes, but if I recall we called them Assertions:

..<https://en.wikipedia.org/wiki/Assertion_(software_development)>

Software also has Invariants, but I don\'t know that either one came
from the Physics world.

..<https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invariants_in_computer_science>

The main difference in software seems to be that assertions are
logical statements about the value of a single variable, while
Invariants apply an assertion to the result of a specified function.

One kind of assertion was visual - coplot a 2D plot of something, plus
a circle, and visually verify concentricity. The eye is _very_ good
at this, so it was a very robust and sensitive test.

I for one used them heavily, with some being used in operation, not
just development. This was done in runtime code, not as a property of
the programming language and/or compiler.

Joe Gwinn

 

[Joe Gwinn]

On Wed, 4 Jan 2023 16:08:37 +0000, Martin Brown
<\'\'\'newspam\'\'\'@nonad.co.uk> wrote:

On 04/01/2023 14:54, bitrex wrote:
On 1/4/2023 9:52 AM, bitrex wrote:
On 1/3/2023 7:30 PM, Phil Hobbs wrote:

I agree that knowing the fundamentals cold is very important.
However, (a) physics isn\'t for everyone, by a long chalk; and (b)
there\'s a glorious intellectual heritage in engineering, so calling
it \'vocational training\' is pejorative.

Cheers

Phil \"Intermediate energy state\" Hobbs


Advanced engineering mathematics:

https://www.ebay.com/itm/194964206310

Which is pretty advanced, I don\'t know how many BS-type EEs know about
the orthogonality of Bessel functions, or regularly use contour
integration for anything.

I once used contour integration to obtain a fringe field correction on a
mass spectrometer magnet. The objective was to take out the first order
aberrations and make the focal plane orthogonal to the optic axis.

It was one of the first electromagnetic optics codes where the magnitude
of the predicted voltages on electrodes was sometime right. Prior to
that you were lucky if it had the right sign! The original code came off
a mainframe and was intended for designing atom smashers. A listing
arrived at the company from academia with my new boss.

Physics was mainly into Chebyshev polynomials for solving wavefunction
equations since it housed one of the world experts in the field.

But not as advanced as \"Advanced Mathematical Methods for Scientists &
Engineers\", which is largely about perturbation methods, boundary
layer theory, and WKB approximations. Sounds fun I guess, I just got a
used copy from Amazon for $8

I would expect stuff like the WKB approximation is regularly used more
in optics design than in circuit design, though.

A bit like Green\'s function I\'m inclined to think that WKB is seldom
used at all now that we have very fast raytracers on the desktop PC. It
may still be taught at undergraduate level today but mainly to weed out
those that are not going to make it as a theoretical physicist (which is
where it was used back in my day as an undergraduate).

Padé rational approximation methods are undergoing something of a
Renaissance. Things go in cycles. I keep waiting for Clifford Algebras
to take off as my supervisor promised they soon would (~2 decades ago).

Things which do have an important place in modern software that is
intended to be provably correct are invariants (borrowed from physics).

Yes, but if I recall we called them Assertions:

..<https://en.wikipedia.org/wiki/Assertion_(software_development)>

Software also has Invariants, but I don\'t know that either one came
from the Physics world.

..<https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invariants_in_computer_science>

The main difference in software seems to be that assertions are
logical statements about the value of a single variable, while
Invariants apply an assertion to the result of a specified function.

One kind of assertion was visual - coplot a 2D plot of something, plus
a circle, and visually verify concentricity. The eye is _very_ good
at this, so it was a very robust and sensitive test.

I for one used them heavily, with some being used in operation, not
just development. This was done in runtime code, not as a property of
the programming language and/or compiler.

Joe Gwinn