Driver to drive?

[panfilero]

On Sunday, April 20, 2014 8:45:55 AM UTC-5, k...@attt.bizz wrote:

On Sat, 19 Apr 2014 19:41:30 -0700 (PDT), panfilero

@gmail.com> wrote:



On Friday, April 18, 2014 8:51:27 PM UTC-5, josephkk wrote:

On Fri, 18 Apr 2014 13:03:27 -0700 (PDT), panfilero <@gmail.com



wrote:







How do measurements off a shunt work for AC, are there OpAmps that can handle that kind of common mode voltage at their inputs? Or is Hall Effect pretty much the way to go for these kinds of things?







Yes. And there are a handful or so of new versions tailored specifically



to that purpose. Search for "positive rail current monitor".











dn apisumop







?-)



Positive rail current monitor? Like a high side shunt monitor? Does this apply for AC? Both sides see high common mode voltage swings, +/- 110Vac ? What opamp can survive that?



Not the safest thing to do but with the appropriate gain, the high

common mode voltage is no problem. If you have a gain of 1/50, the

common mode voltage scales inside a single 5V rail. Of course the

differential signal is also divided by 50 and common mode rejection is

dependent on resistor tolerances so there may be other problems.

Really? The common mode voltage scales down?

Isn't common mode voltage (Vin,inv + Vin,non-inv)/2? so regardless of the gain the input of my opamp would see all 110V right? or maybe I'm misunderstanding something here....

 

[David Brown]

On 16/04/14 17:00, haiticare2011@gmail.com wrote:
> 3. I am a biochemist

Do you /really/ expect anyone to believe that? You think homoeopathy is
valid, 'flu' vaccines and the Human Genome Project are hoaxes, and you
are claiming to be a biochemist!

 

[whit3rd]

On Friday, April 18, 2014 6:51:27 PM UTC-7, josephkk wrote:

On Fri, 18 Apr 2014 13:03:27 -0700 (PDT), panfilero <panfilero@gmail.com

wrote:

How do measurements off a shunt work for AC, are there OpAmps that can handle that kind of common mode voltage at their inputs? Or is Hall Effect pretty much the way to go for these kinds of things?

Yes. And there are a handful or so of new versions tailored specifically
to that purpose. Search for "positive rail current monitor".

The best solution to high common mode voltage is, of course, an isolation
amplifier (input circuit has its own isolated power supply, output circuit
is by transformer or optocoupler, or by voltage-frequency conversion
and acoustic coupling...).

In an AC system, of course, you'd need 'positive rail current' and
'negative rail current' sensing, or the job's only halfway done!
For wye (three phase) systems, that'd become 'only one third done'.

 

[Bill Sloman]

On Tuesday, 22 April 2014 02:10:31 UTC+10, David Brown wrote:

On 16/04/14 17:00, haiticare2011@gmail.com wrote:

3. I am a biochemist

Do you /really/ expect anyone to believe that? You think homoeopathy is valid, 'flu' vaccines and the Human Genome Project are hoaxes, and you are claiming to be a biochemist!

My mother described herself as biochemist, but did point out that since she'd graduated in 1938, most of modern biochemistry had been discovered after she'd had chance to be spoon-fed it. Haitic is probably in a similar situation. Whatever he was taught is now obsolete (or at least a relatively small segment of what he needs to know) and he clearly hasn't kept his knowledge up to date.

--
Bill Sloman, Sydney

 

On Sun, 20 Apr 2014 08:13:59 +0300, upsidedown@downunder.com wrote:

On Sat, 19 Apr 2014 19:41:30 -0700 (PDT), panfilero
panfilero@gmail.com> wrote:

On Friday, April 18, 2014 8:51:27 PM UTC-5, josephkk wrote:
On Fri, 18 Apr 2014 13:03:27 -0700 (PDT), panfilero <@gmail.com

wrote:

How do measurements off a shunt work for AC, are there OpAmps that can handle that kind of common mode voltage at their inputs? Or is Hall Effect pretty much the way to go for these kinds of things?


Yes. And there are a handful or so of new versions tailored specifically

to that purpose. Search for "positive rail current monitor".



dn apisumop


?-)

Positive rail current monitor? Like a high side shunt monitor? Does this apply for AC? Both sides see high common mode voltage swings, +/- 110Vac ? What opamp can survive that?

Most likely just for DC.

The simples high side current monitor would be shunt between a PNP
transistor emitter and base and a high resistance from collector to
ground. Split the resistance into two resistors and get a nice voltage
(say 0..5 V) from that voltage divider proportional to the current
through the shunt.

For AC only, simply use a current transformer.

For AC+DC, use a isolated power supply to feed a V/f chip sitting on
the shunt and send down the frequency modulated signal through
capacitors and/or isolation transformers and then apply f/V
conversion.

For real high common mode voltages, say 400 kVac, use a laser injected
into one fiber to power the current measurement device sitting on the
EHT line, then use an other fiber to digitally transmit down the
measurement.

WoW ! That's an impressive way to measure HV current. Hope I never
have to do that, quite.

1000V is high enough for me.

boB

 

On Mon, 21 Apr 2014 10:32:05 -0700 (PDT), panfilero
<panfilero@gmail.com> wrote:

On Sunday, April 20, 2014 8:45:55 AM UTC-5, k...@attt.bizz wrote:
On Sat, 19 Apr 2014 19:41:30 -0700 (PDT), panfilero

@gmail.com> wrote:



On Friday, April 18, 2014 8:51:27 PM UTC-5, josephkk wrote:

On Fri, 18 Apr 2014 13:03:27 -0700 (PDT), panfilero <@gmail.com

wrote:

How do measurements off a shunt work for AC, are there OpAmps that can handle that kind of common mode voltage at their inputs? Or is Hall Effect pretty much the way to go for these kinds of things?

Yes. And there are a handful or so of new versions tailored specifically
to that purpose. Search for "positive rail current monitor".

dn apisumop

Positive rail current monitor? Like a high side shunt monitor? Does this apply for AC? Both sides see high common mode voltage swings, +/- 110Vac ? What opamp can survive that?
Not the safest thing to do but with the appropriate gain, the high

common mode voltage is no problem. If you have a gain of 1/50, the
common mode voltage scales inside a single 5V rail. Of course the
differential signal is also divided by 50 and common mode rejection is
dependent on resistor tolerances so there may be other problems.

Really? The common mode voltage scales down?

Isn't common mode voltage (Vin,inv + Vin,non-inv)/2? so regardless of the gain the input of my opamp would see all 110V right? or maybe I'm misunderstanding something here....

Look at this way, you have two voltage dividers, one before the shunt,
the other after ther shunt. Assuming the shunt will generate a 1 V
voltage drop and you are using 1/50 _ideal_ voltage dividers, you are
going to measure a 20 mV voltage differences.

Completely doable with low voltages and realizable with existing
resistor tolerances for a few tens of volts, but after that, no hope.

 

On Mon, 21 Apr 2014 10:32:05 -0700 (PDT), panfilero
<panfilero@gmail.com> wrote:

On Sunday, April 20, 2014 8:45:55 AM UTC-5, k...@attt.bizz wrote:
On Sat, 19 Apr 2014 19:41:30 -0700 (PDT), panfilero

@gmail.com> wrote:



On Friday, April 18, 2014 8:51:27 PM UTC-5, josephkk wrote:

On Fri, 18 Apr 2014 13:03:27 -0700 (PDT), panfilero <@gmail.com



wrote:







How do measurements off a shunt work for AC, are there OpAmps that can handle that kind of common mode voltage at their inputs? Or is Hall Effect pretty much the way to go for these kinds of things?







Yes. And there are a handful or so of new versions tailored specifically



to that purpose. Search for "positive rail current monitor".











dn apisumop







?-)



Positive rail current monitor? Like a high side shunt monitor? Does this apply for AC? Both sides see high common mode voltage swings, +/- 110Vac ? What opamp can survive that?



Not the safest thing to do but with the appropriate gain, the high

common mode voltage is no problem. If you have a gain of 1/50, the

common mode voltage scales inside a single 5V rail. Of course the

differential signal is also divided by 50 and common mode rejection is

dependent on resistor tolerances so there may be other problems.

Really? The common mode voltage scales down?

Really! Honest injun!

>Isn't common mode voltage (Vin,inv + Vin,non-inv)/2? so regardless of the gain the input of my opamp would see all 110V right? or maybe I'm misunderstanding something here....

No, the non-inverting input resistor and the resistor from the
non-inverting input to the reference form a voltage divider. If your
gain is 1/50, you have a similar voltage divider between the shunt
resistor and the opamp. As long as the opamp's output is between the
rails, the inverting input is at the same voltage as the
non-inverting, so the same holds on the inverting input.

 

On Mon, 21 Apr 2014 13:45:48 -0700 (PDT), whit3rd <whit3rd@gmail.com>
wrote:

In an AC system, of course, you'd need 'positive rail current' and
'negative rail current' sensing, or the job's only halfway done!
For wye (three phase) systems, that'd become 'only one third done'.

This is trivial with current transformers.

At EHT (above 100 kV) things get a bit more complicated.

 

[John Larkin]

On Mon, 21 Apr 2014 17:31:14 -0400, krw@attt.bizz wrote:

On Mon, 21 Apr 2014 10:32:05 -0700 (PDT), panfilero
panfilero@gmail.com> wrote:

On Sunday, April 20, 2014 8:45:55 AM UTC-5, k...@attt.bizz wrote:
On Sat, 19 Apr 2014 19:41:30 -0700 (PDT), panfilero

@gmail.com> wrote:



On Friday, April 18, 2014 8:51:27 PM UTC-5, josephkk wrote:

On Fri, 18 Apr 2014 13:03:27 -0700 (PDT), panfilero <@gmail.com



wrote:







How do measurements off a shunt work for AC, are there OpAmps that can handle that kind of common mode voltage at their inputs? Or is Hall Effect pretty much the way to go for these kinds of things?







Yes. And there are a handful or so of new versions tailored specifically



to that purpose. Search for "positive rail current monitor".











dn apisumop







?-)



Positive rail current monitor? Like a high side shunt monitor? Does this apply for AC? Both sides see high common mode voltage swings, +/- 110Vac ? What opamp can survive that?



Not the safest thing to do but with the appropriate gain, the high

common mode voltage is no problem. If you have a gain of 1/50, the

common mode voltage scales inside a single 5V rail. Of course the

differential signal is also divided by 50 and common mode rejection is

dependent on resistor tolerances so there may be other problems.

Really? The common mode voltage scales down?

Really! Honest injun!

Isn't common mode voltage (Vin,inv + Vin,non-inv)/2? so regardless of the gain the input of my opamp would see all 110V right? or maybe I'm misunderstanding something here....

No, the non-inverting input resistor and the resistor from the
non-inverting input to the reference form a voltage divider. If your
gain is 1/50, you have a similar voltage divider between the shunt
resistor and the opamp. As long as the opamp's output is between the
rails, the inverting input is at the same voltage as the
non-inverting, so the same holds on the inverting input.

The required precision of the resistors gets crazy as the ratio of bus
voltage to shunt drop goes up.


--

John Larkin Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[David Brown]

On 22/04/14 01:50, Bill Sloman wrote:

On Tuesday, 22 April 2014 02:10:31 UTC+10, David Brown wrote:
On 16/04/14 17:00, haiticare2011@gmail.com wrote:

3. I am a biochemist

Do you /really/ expect anyone to believe that? You think
homoeopathy is valid, 'flu' vaccines and the Human Genome Project
are hoaxes, and you are claiming to be a biochemist!

My mother described herself as biochemist, but did point out that
since she'd graduated in 1938, most of modern biochemistry had been
discovered after she'd had chance to be spoon-fed it. Haitic is
probably in a similar situation. Whatever he was taught is now
obsolete (or at least a relatively small segment of what he needs to
know) and he clearly hasn't kept his knowledge up to date.

That might well explain some of his misconceptions, but I bet your
mother could tell you exactly why homoeopathy doesn't work - as could
every biochemist from long before "alchemy" turned into "chemistry".
It's like being a true believer in the flat earth society, and claiming
to be a satellite engineer.

 

[Martin Brown]

On 18/04/2014 10:57, upsidedown@downunder.com wrote:

On Fri, 18 Apr 2014 09:10:55 +0100, Martin Brown
|||newspam|||@nezumi.demon.co.uk> wrote:

Ten or twenty years before, the spectacle was Fortran compiler vendors
claiming that their compilers generated executable code that was faster
than that produced by assembly programmers. Well, not if you get a
real assembly programmer. But hardware got fast enough that we no
longer had to care.

Sometimes we do when transforming large arrays in realtime. Optimising
the performance of the cache architecture and avoiding pipeline stalls
can be absolutely critical to optimal performance.

One thing to remember when getting algorithms from some old Fortran
math library and then rewrite it in e.g. in C, is that Fortran stored
two (and multiple dimension) arrays in a different way than for
instance C.

No-one who moved from FORTRAN to C and wanted optimum speed ever used
C's poxy way of implementing 2D arrays as an array of pointers to 1D
arrays. The 2D indexing for example was implicitly done as a macro

IDX(i,j,N) which expanded to ((i)*(N)+(j))

All brackets here being essential or algorithms can get scrambled.

Most years some graduate student would bring the VAX to its knees by
trying to transpose a (large for the time) 512x512 image with the naive

for (i = 0; i<512; i++)
for (j = 0; j<512; j++)
x[i,j] := x[j,i];

You can write it like that but it runs glacially slowly with hard page
faults on almost every fetch and store operation.

If the code had been optimized for Fortran array storage mode to
minimize cache/virtual memory misses, the C code would have a huge
number of cache/virtual misses, unless the array indexes are
swapped.

The only thing C had going for it over FORTRAN was that the indexing of
FFTs was a lot more natural with 0 based arrays instead of 1 based.

--
Regards,
Martin Brown

 

On Tue, 22 Apr 2014 08:40:49 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

Most years some graduate student would bring the VAX to its knees by
trying to transpose a (large for the time) 512x512 image with the naive

for (i = 0; i<512; i++)
for (j = 0; j<512; j++)
x[i,j] := x[j,i];

You can write it like that but it runs glacially slowly with hard page
faults on almost every fetch and store operation.

One other way of trashing the performance, is the bad habit of some
programmers using fseek/ftell to get the file size, then uses malloc
(or even calloc) to allocate a buffer and then read the whole file
into the buffer in a single read.

A decade ago an image/video display utility did this. With physical
memory sizes much smaller than today, imagine what happens when the
simple load code (a few statements) encounters a big MPEG2 file (a
gigabyte or more).

Everything goes well, until the physical memory/working set is full.
Then the OS starts to write out dirty pages (the beginning of the
video file) into the page file. This continues until the file is
finally "loaded" into memory. Now, perhaps an hour later, the actual
file processing starts by reading pages from the page file.

At least they should have used memory mapped files (available in most
virtual memory operating systems), in which only the required parts of
the read only file is loaded into memory (no need for writing dirty
pages into a page file).

Thus, a few innocent looking statements can have extreme impact on the
performance.

 

On Monday, April 21, 2014 12:10:31 PM UTC-4, David Brown wrote:

On 16/04/14 17:00, haixxticaxxre2011@gmail.com wrote:

3. I am a biochemist



Do you /really/ expect anyone to believe that? You think homoeopathy is

valid, 'flu' vaccines and the Human Genome Project are hoaxes, and you

are claiming to be a biochemist!

yep - degree from Harvard in it, too!
My "scientific method" does not come from any particular training in it, nor
do I believe in any 'circle the wagons' stance in relation to any field.
In other words, even the 'science' of longevity and health is an open book -
We are not super-scribed by any 'machine' science - consider the finding from
the Nurses Study that friends are the most important health factor!

And to be precise - I did NOT say homeopathy is valid, I said that I keep an
open mind about nearly ALL health practices that are not immediately dangerous.
And, may I ask, who is it that I need to apply to, to do "approved" research?
You?

 

[Phil Hobbs]

On 04/22/2014 03:40 AM, Martin Brown wrote:

On 18/04/2014 10:57, upsidedown@downunder.com wrote:
On Fri, 18 Apr 2014 09:10:55 +0100, Martin Brown
|||newspam|||@nezumi.demon.co.uk> wrote:

Ten or twenty years before, the spectacle was Fortran compiler vendors
claiming that their compilers generated executable code that was faster
than that produced by assembly programmers. Well, not if you get a
real assembly programmer. But hardware got fast enough that we no
longer had to care.

Sometimes we do when transforming large arrays in realtime. Optimising
the performance of the cache architecture and avoiding pipeline stalls
can be absolutely critical to optimal performance.

One thing to remember when getting algorithms from some old Fortran
math library and then rewrite it in e.g. in C, is that Fortran stored
two (and multiple dimension) arrays in a different way than for
instance C.

No-one who moved from FORTRAN to C and wanted optimum speed ever used
C's poxy way of implementing 2D arrays as an array of pointers to 1D
arrays. The 2D indexing for example was implicitly done as a macro

IDX(i,j,N) which expanded to ((i)*(N)+(j))

All brackets here being essential or algorithms can get scrambled.

Most years some graduate student would bring the VAX to its knees by
trying to transpose a (large for the time) 512x512 image with the naive

for (i = 0; i<512; i++)
for (j = 0; j<512; j++)
x[i,j] := x[j,i];

You can write it like that but it runs glacially slowly with hard page
faults on almost every fetch and store operation.

If the code had been optimized for Fortran array storage mode to
minimize cache/virtual memory misses, the C code would have a huge
number of cache/virtual misses, unless the array indexes are
swapped.

The only thing C had going for it over FORTRAN was that the indexing of
FFTs was a lot more natural with 0 based arrays instead of 1 based.

And no COMMON blocks, DATA cards, computed GOTOs, arithmetic IFs, .....

I learned Fortran in the late 70s attempting to debug a radiative
transfer astrophysics code that I didn't understand very well at all. I
sure don't miss it.

Cheers

Phil Hobbs

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

On Tue, 22 Apr 2014 09:07:08 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

On 04/22/2014 03:40 AM, Martin Brown wrote:
On 18/04/2014 10:57, upsidedown@downunder.com wrote:
On Fri, 18 Apr 2014 09:10:55 +0100, Martin Brown
|||newspam|||@nezumi.demon.co.uk> wrote:

Ten or twenty years before, the spectacle was Fortran compiler vendors
claiming that their compilers generated executable code that was faster
than that produced by assembly programmers. Well, not if you get a
real assembly programmer. But hardware got fast enough that we no
longer had to care.

Sometimes we do when transforming large arrays in realtime. Optimising
the performance of the cache architecture and avoiding pipeline stalls
can be absolutely critical to optimal performance.

One thing to remember when getting algorithms from some old Fortran
math library and then rewrite it in e.g. in C, is that Fortran stored
two (and multiple dimension) arrays in a different way than for
instance C.

No-one who moved from FORTRAN to C and wanted optimum speed ever used
C's poxy way of implementing 2D arrays as an array of pointers to 1D
arrays. The 2D indexing for example was implicitly done as a macro

IDX(i,j,N) which expanded to ((i)*(N)+(j))

All brackets here being essential or algorithms can get scrambled.

Most years some graduate student would bring the VAX to its knees by
trying to transpose a (large for the time) 512x512 image with the naive

for (i = 0; i<512; i++)
for (j = 0; j<512; j++)
x[i,j] := x[j,i];

You can write it like that but it runs glacially slowly with hard page
faults on almost every fetch and store operation.

If the code had been optimized for Fortran array storage mode to
minimize cache/virtual memory misses, the C code would have a huge
number of cache/virtual misses, unless the array indexes are
swapped.

The only thing C had going for it over FORTRAN was that the indexing of
FFTs was a lot more natural with 0 based arrays instead of 1 based.


And no COMMON blocks,

What is wrong with COMMON blocks ?

These are just structs. Even if the compiler didn't support any kind
of "include" statements, just make several copies of the COMMON cards
(preferably on cards with different color) and put the cards into the
card deck for each subroutine, this works nicely.

>DATA cards, computed GOTOs, arithmetic IFs, .....

switch/case statements in more recent languages ?

 

On Thursday, April 17, 2014 4:02:58 PM UTC-4, Cydrome Leader wrote:

In sci.electronics.repair krw@attt.bizz wrote:

On Wed, 16 Apr 2014 17:04:52 -0700, John Larkin

jlarkin@highlandtechnology.com> wrote:



On Wed, 16 Apr 2014 19:20:10 -0400, krw@attt.bizz wrote:



On Wed, 16 Apr 2014 18:41:33 +0000 (UTC), Cydrome Leader

presence@MUNGEpanix.com> wrote:



In sci.electronics.repair krw@attt.bizz wrote:

On Tue, 15 Apr 2014 17:56:29 +0000 (UTC), Cydrome Leader

presence@MUNGEpanix.com> wrote:



In sci.electronics.repair krw@attt.bizz wrote:

On Fri, 11 Apr 2014 16:15:44 -0700, John Larkin

jlarkin@highlandtechnology.com> wrote:



On Fri, 11 Apr 2014 18:49:37 -0400, krw@attt.bizz wrote:



On Fri, 11 Apr 2014 07:54:15 -0400, Spehro Pefhany

speffSNIP@interlogDOTyou.knowwhat> wrote:



On Thu, 10 Apr 2014 16:42:37 -0700, the renowned John Larkin

jlarkin@highlandtechnology.com> wrote:



On Thu, 10 Apr 2014 18:37:39 -0400, krw@attt.bizz wrote:



On Thu, 10 Apr 2014 15:07:38 -0700, John Larkin

jlarkin@highlandtechnology.com> wrote:



On Thu, 10 Apr 2014 18:50:31 GMT, Jan Panteltje

pNaonStpealmtje@yahoo.com> wrote:



On a sunny day (Thu, 10 Apr 2014 09:16:12 -0700) it happened John Larkin

jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in

asgdk9d29q9ds74218i3r5me51loi12pm5@4ax.com>:



I avoid battery-powered tools. They are wimpy, and the batteries will die in a

year or two.



You have a cellphone?



Sure, a simple one. I charge it about every other week, and I've

replaced the battery once. But it's not a power tool.



You're not going to get a horsepower or so out of a battery for long,

especially when the battery is two years old.



You're not going to get a "horsepower or so" out of a hand tool.

You're in the stationary tool realm at a HP (Craftsman HPs don't

count).



120 volts, 15 amps is 1800 watts. Lots of circular saws pull 13 amps,

1560 watts.



Cordless circular saws (even small 6.5" ones) are close to useless.



Not so. I have a DeWalt that's quite nice on plywood and such. I

also have an older Makita that's great for cedar siding. It sure as

hell beats a 10lb. corded monster when you're trying to trim a piece

of siding, 15' up a ladder on the side of the house. ;-)



I've got a Hitachi one that came in a kit- cut up few ~2" branches

that were felled by an ice storm and it was already dying.



A circular saw used on a tree? You must be suicidal. Cutting a 2"

diameter branch with a 6" saw? You *have* to be! Haven't you ever

heard of a chain saw, or even a reciprocating saw? ;-)



Aren't trees still made out of wood?



Yes, and fingers are still made of skin and bone; much softer than

even wood. Circular saws are very dangerous things when used by a

someone with no respect for them. They are *not* designed for this

sort of thing.



and a chainsaw is safer?



Than using a circular saw as a chainsaw? You bet your ass! That is

what he's doing, in fact. There is a reason these tools exist.



I can't think of any use of a circular saw that makes it more dangerous

than a chainsaw.



Then you can't think. Each tool has its uses and its dangers. Using

the wrong tool is always dangerous.



I have noticed that, most of the time, there is something within reach

that will work well enough.



Yeah, a friend thought the same thing about hammers, until he used a

framing hammer to drive cut nails. Some ten eye surgeries later he

figured out just what a mistake that was.



is there a special hammer for cut nails?

Not a hammer, but the 4 inch grinder from Harbor Freight with a metal cutoff
wheel on it is what I use. These tools are very NICE - plenty of power, easy to
handle, reliable, and INEXPENSIVE. $10-$20. Around 20,000 rpm as I recall.
These tools are the next step up from a Dremel. You will have no trouble
cutting through a 3/4 inch steel bolt with one. or 1 inch.
I have 5 of them, fitted out wirh: metal cutoff, grinder, flap grinder, and
diamond grinder.
Nice hand balance. 5 stars.

 

[Phil Hobbs]

On 04/22/2014 09:33 AM, upsidedown@downunder.com wrote:

On Tue, 22 Apr 2014 09:07:08 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

On 04/22/2014 03:40 AM, Martin Brown wrote:
On 18/04/2014 10:57, upsidedown@downunder.com wrote:
On Fri, 18 Apr 2014 09:10:55 +0100, Martin Brown
|||newspam|||@nezumi.demon.co.uk> wrote:

Ten or twenty years before, the spectacle was Fortran compiler vendors
claiming that their compilers generated executable code that was faster
than that produced by assembly programmers. Well, not if you get a
real assembly programmer. But hardware got fast enough that we no
longer had to care.

Sometimes we do when transforming large arrays in realtime. Optimising
the performance of the cache architecture and avoiding pipeline stalls
can be absolutely critical to optimal performance.

One thing to remember when getting algorithms from some old Fortran
math library and then rewrite it in e.g. in C, is that Fortran stored
two (and multiple dimension) arrays in a different way than for
instance C.

No-one who moved from FORTRAN to C and wanted optimum speed ever used
C's poxy way of implementing 2D arrays as an array of pointers to 1D
arrays. The 2D indexing for example was implicitly done as a macro

IDX(i,j,N) which expanded to ((i)*(N)+(j))

All brackets here being essential or algorithms can get scrambled.

Most years some graduate student would bring the VAX to its knees by
trying to transpose a (large for the time) 512x512 image with the naive

for (i = 0; i<512; i++)
for (j = 0; j<512; j++)
x[i,j] := x[j,i];

You can write it like that but it runs glacially slowly with hard page
faults on almost every fetch and store operation.

If the code had been optimized for Fortran array storage mode to
minimize cache/virtual memory misses, the C code would have a huge
number of cache/virtual misses, unless the array indexes are
swapped.

The only thing C had going for it over FORTRAN was that the indexing of
FFTs was a lot more natural with 0 based arrays instead of 1 based.


And no COMMON blocks,

What is wrong with COMMON blocks ?

These are just structs. Even if the compiler didn't support any kind
of "include" statements, just make several copies of the COMMON cards
(preferably on cards with different color) and put the cards into the
card deck for each subroutine, this works nicely.

They're unstructured, is what's wrong with them. You can't figure out
where they're visible without an exhaustive search.

DATA cards, computed GOTOs, arithmetic IFs, .....

switch/case statements in more recent languages ?

Order sensitive, unreadable, and unstructured. Switch statements have
none of those problems.

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[David Platt]

In article <5356697C.1070509@electrooptical.net>,
Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

The only thing C had going for it over FORTRAN was that the indexing of
FFTs was a lot more natural with 0 based arrays instead of 1 based.

And no COMMON blocks, DATA cards, computed GOTOs, arithmetic IFs, .....

Hey, half a dozen COMMON blocks, with an EQUIVALENCE statement or two
to make them overlap in memory in interesting ways, was a sure-fire
recipe for excitement, thrills, and desperate 4 AM debugging sessions.

Computed GOTOs weren't really so bad - they're just sort of a switch()
full of gotos, and you could see precisely which variable or
expression was evaluated to control the jump.

It was "assigned" GOTOs (first cousin to the COBOL "ALTER" verb) which
really made things fun, fun, fun. Self-modifying branch logic of the
finest kind (>>shudder<&lt.

 

[Phil Hobbs]

On 04/22/2014 03:58 PM, David Platt wrote:

In article <5356697C.1070509@electrooptical.net>,
Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

The only thing C had going for it over FORTRAN was that the indexing of
FFTs was a lot more natural with 0 based arrays instead of 1 based.

And no COMMON blocks, DATA cards, computed GOTOs, arithmetic IFs, .....

Hey, half a dozen COMMON blocks, with an EQUIVALENCE statement or two
to make them overlap in memory in interesting ways, was a sure-fire
recipe for excitement, thrills, and desperate 4 AM debugging sessions.

Computed GOTOs weren't really so bad - they're just sort of a switch()
full of gotos, and you could see precisely which variable or
expression was evaluated to control the jump.

It was "assigned" GOTOs (first cousin to the COBOL "ALTER" verb) which
really made things fun, fun, fun. Self-modifying branch logic of the
finest kind (>>shudder<&lt.

http://www.fortran.com/come_from.html

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[David Brown]

On 22/04/14 18:11, haiticare2011@gmail.com wrote:

On Monday, April 21, 2014 12:10:31 PM UTC-4, David Brown wrote:
On 16/04/14 17:00, haixxticaxxre2011@gmail.com wrote:

3. I am a biochemist



Do you /really/ expect anyone to believe that? You think homoeopathy is

valid, 'flu' vaccines and the Human Genome Project are hoaxes, and you

are claiming to be a biochemist!

yep - degree from Harvard in it, too!
My "scientific method" does not come from any particular training in it, nor
do I believe in any 'circle the wagons' stance in relation to any field.
In other words, even the 'science' of longevity and health is an open book -
We are not super-scribed by any 'machine' science - consider the finding from
the Nurses Study that friends are the most important health factor!

And to be precise - I did NOT say homeopathy is valid, I said that I keep an
open mind about nearly ALL health practices that are not immediately dangerous.
And, may I ask, who is it that I need to apply to, to do "approved" research?
You?

If you have the remotest concept of what "science" means, you have
failed to show it in this thread.

I have already explained how "friends as a health factor" works, as have
others - it is a very simple and obvious effect that is well-known to
many (and has been accepted practice ever since the first early
proto-human expressed sympathy towards another). The study you are so
fond of mentioning gives an idea of the relative strength of this effect
compared to other effects in a statistical analysis - useful scientific
information, but hardly ground-breaking.

I have have already explained how homoeopathy (please learn to spell the
word) can often be harmful.

You do not need my permission to do any research - but if you did, I
would happily approve. Please do some reading and educate yourself
before embarrassing yourself more in public.