ELF detector

[John Woodgate]

I read in sci.electronics.design that Ken Smith
<kensmith@green.rahul.net> wrote (in <cj73kq$bsp$3@blue.rahul.net&gt
about 'ELF detector', on Sun, 26 Sep 2004:

In article <bkJTvRCl5mVBFwXa@jmwa.demon.co.uk>,
John Woodgate <noone@yuk.yuk> wrote:
I read in sci.electronics.design that Ken Smith
kensmith@green.rahul.net> wrote (in <cj4o62$g7l$8@blue.rahul.net&gt
about 'ELF detector', on Sat, 25 Sep 2004:

I doubt software can do it. You need to divide by zero. Most
programmers have a hard time writing code that does that successfully.

IF DIVISOR = 0, THEN RESULT = 1E+38 ELSE RESULT = DIVIDEND/DIVISOR

It's the order in which you write it that matters. (;-)

ROSIVID/DNEDIVID = TLUSER ESLE 83+E! = TLUSER NEHT .0 = ROSIVID FI

Would yeld a different result

Perfectly valid code in HSILGNE.

but you haven't successfully divided by zero
since the logic of your code avoids the divide completely if the DIVISOR
is zero.

of course, because N/0 is mathematically nonsense, so it *can't* be
evaluated rigorously.

There is a trick you can use in C++ to do it. C++ allows all operators to
be overloaded. Thus in C++ you can make up you own rules about ADD,
SUBTRACT, MULTIPLY and DIVIDE to that 1/0 is perfectly legal.

In C++ you can make the main part of your program:

int main(void){ return 1/0; }


Is that essentially different from my pre-emptive *redefinition* of N/0

as '= 1E38'?
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

 

[Ken Smith]

In article <4156700E.AD098E76@earthlink.net>,
Robert Baer <robertbaer@earthlink.net> wrote:

Ken Smith wrote:

[...]
You didn't give enough details. How big does the loop have to be to do
the "0-" part of the range?

--
--
kensmith@rahul.net forging knowledge

Depends on the sensitivity you want.
Obviously, you cannot make a loop any where near 1/4 wavelength...

When you go to normalize the gain of the induction loop at zero Hz, you
have to write some very tricky software. You have to divide by zero to
get any sensitivity you want. Most programmers would have trouble
designing a divide by zero routine that is accurate to more than 1 bit.


You could use a GMR or other magnetoresistive device.



--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <bkJTvRCl5mVBFwXa@jmwa.demon.co.uk>,
John Woodgate <noone@yuk.yuk> wrote:

I read in sci.electronics.design that Ken Smith
kensmith@green.rahul.net> wrote (in <cj4o62$g7l$8@blue.rahul.net&gt
about 'ELF detector', on Sat, 25 Sep 2004:

I doubt software can do it. You need to divide by zero. Most
programmers have a hard time writing code that does that successfully.

IF DIVISOR = 0, THEN RESULT = 1E+38 ELSE RESULT = DIVIDEND/DIVISOR

It's the order in which you write it that matters. (;-)

ROSIVID/DNEDIVID = TLUSER ESLE 83+E! = TLUSER NEHT .0 = ROSIVID FI

Would yeld a different result but you haven't successfully divided by zero
since the logic of your code avoids the divide completely if the DIVISOR
is zero.

There is a trick you can use in C++ to do it. C++ allows all operators to
be overloaded. Thus in C++ you can make up you own rules about ADD,
SUBTRACT, MULTIPLY and DIVIDE to that 1/0 is perfectly legal.

In C++ you can make the main part of your program:

int main(void){ return 1/0; }


--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <jjFtuWAUgxVBFwAS@jmwa.demon.co.uk>,
John Woodgate <noone@yuk.yuk> wrote:

I read in sci.electronics.design that Ken Smith
[...]
There is a trick you can use in C++ to do it. C++ allows all operators to
be overloaded. Thus in C++ you can make up you own rules about ADD,
SUBTRACT, MULTIPLY and DIVIDE to that 1/0 is perfectly legal.

In C++ you can make the main part of your program:

int main(void){ return 1/0; }


Is that essentially different from my pre-emptive *redefinition* of N/0
as '= 1E38'?

A few differences:

(1)
What you showed could be figured out by the maintainers. The C++ version
can easily be written so that no-one can understand it.

(B)
The version you did is discontinuous near zero. In C++ you can redefine
the divide so that X/Y <==> cos(X/Y) yelding a nice smooth curve near
zero.

(iii)
The 1E38 is machine dependant.

(d)
C++ is coded in lower case.

--
--
kensmith@rahul.net forging knowledge

 

[Robert Baer]

Ken Smith wrote:

In article <jjFtuWAUgxVBFwAS@jmwa.demon.co.uk>,
John Woodgate <noone@yuk.yuk> wrote:
I read in sci.electronics.design that Ken Smith
[...]
There is a trick you can use in C++ to do it. C++ allows all operators to
be overloaded. Thus in C++ you can make up you own rules about ADD,
SUBTRACT, MULTIPLY and DIVIDE to that 1/0 is perfectly legal.

In C++ you can make the main part of your program:

int main(void){ return 1/0; }


Is that essentially different from my pre-emptive *redefinition* of N/0
as '= 1E38'?

A few differences:

(1)
What you showed could be figured out by the maintainers. The C++ version
can easily be written so that no-one can understand it.

(B)
The version you did is discontinuous near zero. In C++ you can redefine
the divide so that X/Y <==> cos(X/Y) yelding a nice smooth curve near
zero.

(iii)
The 1E38 is machine dependant.

(d)
C++ is coded in lower case.

--
--
kensmith@rahul.net forging knowledge

Reply to option (d): That is because the programmers are too damn lazy
to use mixed case.

 

[John Woodgate]

I read in sci.electronics.design that Ken Smith
<kensmith@green.rahul.net> wrote (in <cj7idr$nmi$1@blue.rahul.net&gt
about 'ELF detector', on Sun, 26 Sep 2004:

(1)
What you showed could be figured out by the maintainers. The C++
version can easily be written so that no-one can understand it.

I agree that is the whole justification for the use of C++ for anything.

(B)
The version you did is discontinuous near zero. In C++ you can redefine
the divide so that X/Y <==> cos(X/Y) yelding a nice smooth curve near
zero.

But you often don't want to *disguise* the 'divide by zero' because it
indicates a problem further up the code. Also, how can replacing, say,
136/0 by cos(136/0) = ?? make a smooth curve when the adjacent points
are cos(135/0.001) = 0.87 and cos(137/-0.003) = 0.89?

(iii)
The 1E38 is machine dependant.

So, replace by the outlier of your choice (or the one dictated by your
genes and memes).

(d)
C++ is coded in lower case.

Oh, well, you're obviously completely right, then. That's an
*****ESSENTIAL**** difference.
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

 

[Mike Monett]

Ken Smith wrote:

[...]

(B) The version you did is discontinuous near zero. In C++ you can
redefine the divide so that X/Y <==> cos(X/Y) yelding a nice
smooth curve near zero.

kensmith@rahul.net forging knowledge

Ken, my math is shaky at best, especially near infinity. Wouldn't
cos(X/Y) give an infinite number of zero crossings as X<>0 and Y-->0?

Best Wishes,

Mike Monett

 

[Ken Smith]

In article <AOx1lzAGK8VBFwXa@jmwa.demon.co.uk>,
John Woodgate <noone@yuk.yuk> wrote:

I read in sci.electronics.design that Ken Smith
kensmith@green.rahul.net> wrote (in <cj7idr$nmi$1@blue.rahul.net&gt
[...]
(B)
The version you did is discontinuous near zero. In C++ you can redefine
the divide so that X/Y <==> cos(X/Y) yelding a nice smooth curve near
zero.

But you often don't want to *disguise* the 'divide by zero' because it
indicates a problem further up the code. Also, how can replacing, say,
136/0 by cos(136/0) = ?? make a smooth curve when the adjacent points
are cos(135/0.001) = 0.87 and cos(137/-0.003) = 0.89?

You are right. I messed up. I should have written something like cos(X+Y)

The whole point of C++ is information hiding isn't it? You want to hide
as much information as you can spread over about 50 *.h files so the
maintainer has no hope of finding the bugs.

This is part of the reason why there is much more code reuse in the
Fortran community than the C++ one.


--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <4157C48D.7E82@spam.com>, Mike Monett <no@spam.com> wrote:

Ken Smith wrote:

[...]

(B) The version you did is discontinuous near zero. In C++ you can
redefine the divide so that X/Y <==> cos(X/Y) yelding a nice
smooth curve near zero.

kensmith@rahul.net forging knowledge

Ken, my math is shaky at best, especially near infinity. Wouldn't
cos(X/Y) give an infinite number of zero crossings as X<>0 and Y-->0?

Your seems to be better than mine were at that moment in time. Yes I
messed up on that one.

--
--
kensmith@rahul.net forging knowledge

 

[Jamie]

just need a fraction byte


Ken Smith wrote:

In article <4156700E.AD098E76@earthlink.net>,
Robert Baer <robertbaer@earthlink.net> wrote:

Ken Smith wrote:

[...]

You didn't give enough details. How big does the loop have to be to do
the "0-" part of the range?

--
--
kensmith@rahul.net forging knowledge

Depends on the sensitivity you want.
Obviously, you cannot make a loop any where near 1/4 wavelength...


When you go to normalize the gain of the induction loop at zero Hz, you
have to write some very tricky software. You have to divide by zero to
get any sensitivity you want. Most programmers would have trouble
designing a divide by zero routine that is accurate to more than 1 bit.


You could use a GMR or other magnetoresistive device.